Hello,
I don't know this part of the code and I haven't looked at it so my
comment is only conceptual but maybe it can help you to understand it
better so I comment on this anyway.
On Wed, 20 Mar 2013, "Rodolfo García Peñas (kix)" wrote:
Now, the Dock and the Clip are WDock structs, but the icons attached to the
Clip or the Dock are WAppIcons. When we create the Dock/Clip we do something
like:
What's wrong with this? The WDock and WAppIcon are separate objects where
the dock (or clip) is holding several app icons. But app icons are not
only used for docks, they also exist for running applications that are not
docked so they are a separate entity. You seem to think around structures
and functions but the original design was really object oriented so you
should think about objects and methods instead. (This may now be harder to
see because of the renaming of some CamelCaseFunctionNames to
underscore_function_names for no obvious reason which made a bit of a mess
with half the method names following one convention with others still
following the other convention. Also you have changed the parameters of
some of the methods not following the object oriented design which may
have messed up some things in the past.)
- Create the Dock (WDock struct)
- Create a WAppIcon with the Dock image (WAppIcon struct)
- Assign the Dock to the WAppIcon :-?!!
This makes sense if you think about creating a dock then creating app
icons for docked applications and putting them on the dock by assigning
the parameter of the app icon which shows which dock it is atteched to.
I'm only guessing here but I think this may have been the original design.
That makes some things difficult. For example, we have different functions to
create the Clip/Dock (wDockCreate()) or restore it (for example
wClipRestoreState()), but these functions returns different structs
(wDockCreate returns a WDock, wClipRestoreState a WAppIcon).
This may be a case where the object oriented design was not followed and
wClipRestoreState may be an odd function which is not really a method of
WDock despite the name suggesting this.
Other example, with the Dock. The Dock is something like:
1. struct WAppIcon->dock is the pointer for the struct WDock
This is a property of the WAppIcon object.
2. struct WDock has an icon_array, with WAppIcons.
Which is a variable of the WDock object and has nothing to do with the
previous as they belong to different objects.
3. The first WAppIcon in the array ([0]), is the WAppIcon for the dock
Which makes sense since the dock itself has an app icon too.
Then, we have something like:
WDock->icon_array[0]->dock = WDock
Which is correct considering the above as the app icon for the dock
itself is always attached to the same dock so its dock property refers to
itself. Why is this a problem? These are really two independent objects
(or should be).
Probably, the best option is assign a different WAppIcon struct for the
Dock/Clip icon, outside the icon_array. Something like:
WDock->icon_array for WAppIcons
WDock->icon for the WAppIcon for the dock/clip.
Why would that be better than using icon_array[0] for the WAppIcon for the
dock. Your suggestion just makes the new icon variable of the WDock object
hold what's now in icon_array[0] (and probably shifting all other app
icons in the array or making it 1 based instead of 0 based both of which
makes it possible to break things due to this change). What would this
bring apart from changing code?
But, anyway, I think return WAppIcon when we are trying to create a WDock
struct is wrong and all functions about Dock/Clip should work with WDock
structs.
This could be true in case of wClipRestoreState but also note that
creating a dock involves creating the attached app icon objects too so
there should be something returning WAppIcons (probably wIconCreate...
which have since been renamed and changed). In case of wClipRestoreState
the question is why is it not just wDockRestoreState(scr, state, WM_CLIP)?
So the bottom line is that when changing code try to keep in mind the
original object oriented design (that may have not been followed in some
cases at the first place so it may need to be corrected) and try to make
changes that does not break it if possible.
Another thing related to this is the naming convention. Following one or
another naming convention is a matter of style and preference but having
mixed up convention is the worse option. OpenStep (which was an obvious
inspiration for Window Maker) uses CamelCase names for its objects and
methods while Objective-C allows mixing object oriented code with plain C.
A useful convention for Window Maker may be to keep CamelCase names for
parts following an object oriented design (objects and methods) while
using underscore_names for functions and structures used as plain C
constructs to clearly differentiate the two. Or to stick to one or the
other convention but avoid mixing the two at least within one object class
to make the code more readable.
I hope these comments can be somewhat helpful even if not directly
answering your questions.
Regards,
BALATON Zoltan
