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.
[repo.or.cz] wmaker-crm.git branch next updated: wmaker-0.95.4-27-g4222204
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project wmaker-crm.git.
The branch, next has been updated
via 404abc2118cafcc9c3e048f03235422c0e9f (commit)
via 25d083a85fe6182b598dc75bd0b74b66613b4853 (commit)
via bb48c355223d33fd2237b5e6c5c15b9aab3ce876 (commit)
via 42a4d95e5b17bc6f77289b911572a8148b0bc31a (commit)
via 309d5c0d1a8a136fd163fcc50a08933e22e9b2a4 (commit)
via 53d31c7bbd7e97129b0d96d48c85e161c2d1b087 (commit)
from 066de301df2f07c614b77e7a2bbadd9ff1342e46 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://repo.or.cz/w/wmaker-crm.git/commit/404abc2118cafcc9c3e048f03235422c0e9f
commit 404abc2118cafcc9c3e048f03235422c0e9f
Author: Rodolfo GarcÃa Peñas (kix) k...@kix.es
Date: Wed Mar 20 04:02:19 2013 +0100
Workspace clip creation in two steps
This patch assigns always the clip to NULL and only if the clip is
needed is created.
This patch mainly is more clear/clean.
diff --git a/src/workspace.c b/src/workspace.c
index 3734b49..491452b 100644
--- a/src/workspace.c
+++ b/src/workspace.c
@@ -88,16 +88,15 @@ int wWorkspaceNew(WScreen *scr)
wspace = wmalloc(sizeof(WWorkspace));
wspace-name = NULL;
+ wspace-clip = NULL;
if (!wspace-name) {
wspace-name = wmalloc(strlen(_(Workspace %i)) + 8);
sprintf(wspace-name, _(Workspace %i),
scr-workspace_count);
}
- if (!wPreferences.flags.noclip) {
+ if (!wPreferences.flags.noclip)
wspace-clip = wDockCreate(scr, WM_CLIP);
- } else
- wspace-clip = NULL;
list = wmalloc(sizeof(WWorkspace *) * scr-workspace_count);
http://repo.or.cz/w/wmaker-crm.git/commit/25d083a85fe6182b598dc75bd0b74b66613b4853
commit 25d083a85fe6182b598dc75bd0b74b66613b4853
Author: Rodolfo GarcÃa Peñas (kix) k...@kix.es
Date: Wed Mar 20 04:02:18 2013 +0100
Removed extra XClearWindow call
The function XClearWindow() is called twice, we can remove one.
See the asterisks (**):
Before the call to wIconPaint():
-8--
+++ b/src/icon.c
@@ -621,7 +621,6 @@ void update_icon_pixmap(WIcon *icon)
XSetWindowBackgroundPixmap(dpy, icon-core-window,
icon-pixmap);
/* Paint it */
** XClearWindow(dpy, icon-core-window);
wIconPaint(icon);
}
-8--
First call in wIconPaint() function:
-8--
void wIconPaint(WIcon *icon)
{
WScreen *scr = icon-core-screen_ptr;
int x, l, w;
char *tmp;
** XClearWindow(dpy, icon-core-window);
-8--
diff --git a/src/icon.c b/src/icon.c
index 62f618a..2c9b27d 100644
--- a/src/icon.c
+++ b/src/icon.c
@@ -621,7 +621,6 @@ void update_icon_pixmap(WIcon *icon)
XSetWindowBackgroundPixmap(dpy, icon-core-window,
icon-pixmap);
/* Paint it */
- XClearWindow(dpy, icon-core-window);
wIconPaint(icon);
}
http://repo.or.cz/w/wmaker-crm.git/commit/bb48c355223d33fd2237b5e6c5c15b9aab3ce876
commit bb48c355223d33fd2237b5e6c5c15b9aab3ce876
Author: Rodolfo GarcÃa Peñas (kix) k...@kix.es
Date: Wed Mar 20 04:02:17 2013 +0100
Window attributes moved to wCoreCreateTopLevel
The function wCoreCreateTopLevel() is used in two files (icon.c and
framewin.c), but after create the window, some attributes are changed.
This patch moves the change inside the wCoreCreateTopLevel(), avoiding to
call XChangeWindowAttributes() after the window creation. Now the window
is created in only one step, with all the final attributes.
Some details:
- The function wCoreCreateTopLevel() has now one argument more, the
border pixel color. This attribute was used always as the screen
frame_border_pixel, but in icon.c the attribute is changed to
white_pixel. Now the function wCoreCreateTopLevel() receives the
value frame_border_pixel in framewin.c and scr-white_pixel in
icon.c, as argument.
- The vmask and attribs variables and the call to XChangeWindowAttributes()
are removed in framewin.c and icon.c. The values CWSaveUnder for vmask and
attribs.save_under = True are used if wPreferences.use_saveunders is True.
- CWBorderPixel is not needed in icon.c, because was previously set in
wcore.c!
diff --git a/src/framewin.c
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
