Two Steps from [the S]hell

[Z98]

https://www.reactos.org/node/908

[Pi_User5]

Where I find these commit logs?

[Black_Fox]

One of the ways to see them is this: http://svn.reactos.org/svn/reactos/bran ... /?view=log
There are half a dozen ways to check, I usually check up here: http://svn.reactos.org/svn/reactos?view=revision

[Pi_User5]

One of the ways to see them is this: http://svn.reactos.org/svn/reactos/bran ... /?view=log
There are half a dozen ways to check, I usually check up here: http://svn.reactos.org/svn/reactos?view=revision

What revision?

[Black_Fox]

There's no "revision", it was tens of revisions/commits All the "new shell" work is happening in the "shell-experiments" branch (the first linked one), so if you take a look there, you'll see just the relevant work.

[Pi_User5]

There's no "revision", it was tens of revisions/commits All the "new shell" work is happening in the "shell-experiments" branch (the first linked one), so if you take a look there, you'll see just the relevant work.

I am trying to figure out the interesting things he mentioned:

P.S.: Some interesting things happened over the weekend, but you will have to wait for next week’s report (or read the commit logs from the branch) to learn about them!

[PurpleGurl]

As for interesting things, here is what I could glean:

Fix GCC build.
Implement hiding the statusbar from the view menu.
Fix crash when showing the Printers shell folder
Create a new header to simplify C++ code.
Add a couple of macros needed when aggregation with ATL becomes possible.
Conversion of the codebase from C to C++ and make use of C++ classes for COM objects.
Code refactoring
Simplify WINE syncs and do some syncs that are due.
Begin improving shell folders implementation

[Pi_User5]

As for interesting things, here is what I could glean:

Fix GCC build.
Implement hiding the statusbar from the view menu.
Fix crash when showing the Printers shell folder
Create a new header to simplify C++ code.
Add a couple of macros needed when aggregation with ATL becomes possible.
Conversion of the codebase from C to C++ and make use of C++ classes for COM objects.
Code refactoring
Simplify WINE syncs and do some syncs that are due.
Begin improving shell folders implementation

Thanks!

[timmay2019]

As for interesting things, here is what I could glean:

Fix GCC build.
Implement hiding the statusbar from the view menu.
Fix crash when showing the Printers shell folder
Create a new header to simplify C++ code.
Add a couple of macros needed when aggregation with ATL becomes possible.
Conversion of the codebase from C to C++ and make use of C++ classes for COM objects.
Code refactoring
Simplify WINE syncs and do some syncs that are due.
Begin improving shell folders implementation

I believe there has also been some works on NTFS as well. There are pictures of NTFS working (to an extent) in ROS. Super exciting .

[knowmad]

Reading NTFS volumes and files seems to be coming along nicely I wonder how far off it is that REACTOS will be able to write them though.

[PurpleGurl]

I believe there has also been some works on NTFS as well. There are pictures of NTFS working (to an extent) in ROS. Super exciting .

That is not related to the shell branch or David's work, however. That is what Pierre is doing in trunk, and I am impressed.

[vicmarcal]

Btw, regarding NTFS, you can't miss ReactOS Twitter. From time to time Heisspiter is sharing some pics there and we RT them.
ReactOS Twitter: @Reactos
And regarding [the S]hell, I want to see what does David have in mind...

[justincase]

You guys have been making it difficult to keep up with you.
As with the last few weeks I'm still posting shell-experiments builds to http://www.mediafire.com/folder/fu9y0equ5nz39.

And for the record, I personally like to view the commit logs via ReactOS' FishEye instance. Specifically the shell-experiments branch's commit logs are at http://code.reactos.org/changelog/react ... xperiments, the trunk commit logs are at http://code.reactos.org/changelog/reactos/trunk/reactos, and unless I'm looking for something specific (e.g. the log of shell-experiments commits) I'll usually just read them all together at http://code.reactos.org.

And just about every time I see "[the S]hell" I read it first as "the S[pecial ]hell". (this link is for people who don't already get the reference)

[Webunny]

Interesting read, as always.

As an aside though, the "I believe this is for a similar reason to why I can’t play chess: I can either see the big picture, or the details, but not both at once." sounds a bit strange. I know it was mostly used allegorically, but in fact, chess doesn't need to have a 'big picture', since there are 169518829100544000000000000 possible moves after the first ten moves. Granted, not all these moves make sense, and most can be outright discarded, but which ones are useful and which not, is wholly dependent on what moves your opponent makes, so there is no 'long term' way to know how to achieve the only big picture (well, rather a goal) there is: to give checkmate. Chess is played by analysing what your opponent did and think ahead for all relevant (=see my comment above; one does not have to calculate every last one of them) possibilities. However, even when disregarding a lot of them outright, it becomes increasingly difficult to predict, the further one goes. Depending on your level, you can go 4-6 moves ahead, grandmasters even 8-10, but then one invariably comes to a halt. (That is to say, your prediction becomes increasingly unlikely, even when going for the most rational moves). Especially in the 'middlegame' (I'm not sure how this is called in English), it gets extremely difficult in that regard. During the opening and the endgame, it's relative easy in comparison, since the possibilities (of good moves) are rather limited. Most openings, for instance, are done to death, so you won't see much surprises there for the first 5 moves. It is, however, infeasible to have any specific 'big picture' into mind as to HOW one is going to be able to give checkmate (even; if), the most one can do is have a 'big goal' of giving checkmate and a vague idea of how one is going to play 'defensive, offensive...). Further down, one can also decide which 'main focus' one is going to use (for instance, an attack on the kings' wing), but even that is dependent already on the actions taken by ones' opponent, who also anticipates your moves, obviously.

I don't think that this is the case for a program, though. While complex, the program is not sentient enough to actually make itself more difficult for you to debug it.

At least, I hope.

[BrentNewland]

Because the shell wasn’t prepared for this situation, it would fail to initialize both the start menu and the Favorites menu. I fixed both, but it turns out the livecd doesn’t have a Favorites folder at all, so the problem remains that there is no Favorites menu to show. It should be fixed at some point so that the livecd contains an empty Favorites folder, or possibly one with some URL shortcuts for the website, forums and such.

You need to take into account the possibility a user will delete their favorites folder. It needs to check if the favorites folder exists, and create it if it doesn't.