Re: Docks and AppIcons
On 20.03.2013 20:37, Rodolfo García Peñas (kix) wrote: [snip] Comments? You are using git. Make a branch and make the changes if you feel like. If it does not work, you learned something. If it works we can review it here... Best regards Andreas -- (`-''-/).___..--''`-._ `o_ o ) `-. ( ).`-.__.`) (_Y_.)' ._ ) `._ `. ``-..-' _..`--'_..-_/ /--'_.' .' (il).-'' (li).' ((!.-' Andreas Tscharner a...@vis.ethz.ch ICQ-No. 14356454 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Docks and AppIcons
Andreas Tscharner a...@vis.ethz.ch escribió: On 20.03.2013 20:37, Rodolfo García Peñas (kix) wrote: [snip] Comments? Hi Andreas, You are using git. Make a branch and make the changes if you feel Yes, and no. I have a lot of branches here (Really, A LOT). When I send patches, is only a part of my branches here. like. If it does not work, you learned something. If it works we can review it here... Yes, but after the review, the patches should be uploaded. If Carlos thinks that we should work only in bugs, not in big/deep changes what will happend? Perhaps is not bad idea stop here for a while with deep changes. Saludos, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Docks and AppIcons
On Thu, 21 Mar 2013 at 9:33:25 +, Rodolfo García Peñas (kix) wrote: If Carlos thinks that we should work only in bugs, not in big/deep changes what will happend? Perhaps is not bad idea stop here for a while with deep changes. I should say I'm a bit nervous about deep changes at this point, that's all. But hey, if deep changes occur as the result of _many_ patches each doing one small obviously-correct-and-showing-good-taste change at a time, then why not? For example, I really liked your six patches from yesterday (they reduce the text size of wmaker and they make the code more straightforward). If you think your deep changes can be built upon these kind of building blocks, then you should go for it. But needless to say, I would feel more confortable if more people step in and review the code. Asking a few questions and trying to come up with scenarios where things would break would be helpful. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Docks and AppIcons
begin quoting Rodolfo Garc??a Pe??as (kix) as of Thu, Mar 21, 2013 at 01:52:50AM +0100: On 20/03/2013 22:59, Carlos R. Mafra wrote: [snip] Massive cleanups in core objects smells like trouble and should have a very compelling reason to be accepted at this (very stable) point. Stability is good! I can continue with my other things! :-) Ok, no problem. The current code seems to be stable, but we now that some things could be better. We can stop here for a while and continue testing this stable code and only solve bugs. If the only problem with the code now is the underlying design, then rewriting the code won't necessarily solve the problem; it might be better to describe the current design, and how it is deficient, and discuss that... and work out a path from here to somewhere better. But the problem is that (probably) we are building over code with some problems. I am not talking about code with bugs, is about bad design. This design make difficult to do some things (like xrandr, yes) and other things. Yes the things works, but that doesn't mean that they are fine. I like the metaphor of technical debt. Deficient design borrows against the future, and it must eventually be paid off. It's easier to make small payments than large payments, as large payments are painful, and might contain hidden debt all their own. This is also where automated unit tests and refactoring techniques can help. [snip] Finally, if the code is frozen for a while with changes about design, could be a good idea check the documentation, the web and create a BTS in windowmaker.org. I cc John for the BTS. Mmmm documentation. -S. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Docks and AppIcons
2 considerations on this subject: - a code which appears to be stable is not necessarily correct (Heisenbugs are uncomfortably common :/) - besides reviewing the code many people can use the next branch and test new versions cheers, Harodo On Thu, Mar 21, 2013 at 7:16 AM, Carlos R. Mafra crma...@gmail.com wrote: On Thu, 21 Mar 2013 at 9:33:25 +, Rodolfo García Peñas (kix) wrote: If Carlos thinks that we should work only in bugs, not in big/deep changes what will happend? Perhaps is not bad idea stop here for a while with deep changes. I should say I'm a bit nervous about deep changes at this point, that's all. But hey, if deep changes occur as the result of _many_ patches each doing one small obviously-correct-and-showing-good-taste change at a time, then why not? For example, I really liked your six patches from yesterday (they reduce the text size of wmaker and they make the code more straightforward). If you think your deep changes can be built upon these kind of building blocks, then you should go for it. But needless to say, I would feel more confortable if more people step in and review the code. Asking a few questions and trying to come up with scenarios where things would break would be helpful. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. -- = Haroldo Gambini Santos Computing Department Universidade Federal de Ouro Preto - UFOP email: haroldo [at ] iceb.ufop.br home/research page: www.decom.ufop.br/haroldo
Re: Docks and AppIcons
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
Docks and AppIcons
Hi, I was thinking about the docks and appicons in wmaker, and probably we should work in this code. 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: - Create the Dock (WDock struct) - Create a WAppIcon with the Dock image (WAppIcon struct) - Assign the Dock to the WAppIcon :-?!! 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). Other example, with the Dock. The Dock is something like: 1. struct WAppIcon-dock is the pointer for the struct WDock 2. struct WDock has an icon_array, with WAppIcons. 3. The first WAppIcon in the array ([0]), is the WAppIcon for the dock Then, we have something like: WDock-icon_array[0]-dock = WDock 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. 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. Comments? Cheers, kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Docks and AppIcons
On Wed, 20 Mar 2013 at 20:37:39 +0100, Rodolfo García Peñas (kix) wrote: 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. Comments? Unless you find bugs I'd recomend to not touch these things now. Because despite some unusual things at some places, all that code has been proven by time and it simply works. And at this moment I think that preserving the stability of wmaker is much more important than anything else. Small additions here and there, small tweaks to improve the usability is how the development should proceed -- there were some people in wmaker-user wanting to move windows to other workspaces using keyboard shortcuts, and I think wmaker could have that option. The (mis)behavior of the xrandr code is also one outstanding thing which annoys some people. Massive cleanups in core objects smells like trouble and should have a very compelling reason to be accepted at this (very stable) point. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
