Re: [PATCH] Basic WINGs theming
Carlos, I was a window maker user back in the 20th century. I agree with you that the priority should be stability but I would love to see improvements and new features in the years to come. I do not think that adding new features necessarily bloats software. Today's software is slow due to poor design and, mainly, bad programmers who are used to many unnecessary layers of libraries and virtual machines. Good programmers can write large and efficient programs. Em 14/11/2013 20:21, "Paul Seelig" escreveu: > On 11/14/2013 08:00 PM, Carlos R. Mafra wrote: > > People argue that "new users" will like to change widget colors in the > _future_. > > I argue that old users don't care _now_. > > > Well, i am one of those old users, if not even one of the very old users > of wmaker. I use it since at least since the year 2000, if not even > earlier. There is even a changelog entry of the official Debian package > of wmaker 0.91.0-5 from Fri, 07 Jan 2005 citing my name, while > mentioning that i pointed to a patch by our estimated currrent list > member Iain Patterson. Is this old enough? Time certainly flies. :) > > Being such an old user, i really wouldn't have minded already in the > long gone _past_ if wmaker would finally be able to change widget colors > in order to be more flexible while trying to create a more homogeneous > desktop without having to subdue oneself to WINGs' color limitations. > But i am repeating myself. :) > > At the very same time i defintely would very welcome those functional > enhancements you mentioned in an earlier message within this thread, > namely "a patch to implement resizing by dragging the corners or a patch > to be able to navigate items in a list using the keyboard keys". And i > would add things like copy and paste via keyboard shortcuts, which > already wrote about in this list a few weeks/months ago. > > It would be great to have some kind of official TODO or roadmap > containing these enhancement ideas officially published somewhere, in > order to provide some guidance for interested developers. > > Yes, "changing the colors does not hurt either" is one way to put it, > but i would rather express it as "enabling WINGs to be more flexible and > adaptive" for those users who are trying to design a minimally > homogeneous desktop in an absolutely heterogeneous world of Linux > desktops and applications. We are in the 21st century now, not in 1995 > anymore. > > In fact, as much as i would dislike a overturning revolution in wmaker, > i definitely would not mind some more evolution in both functionality > and design capabilities. > > I hope i still count as one of those "old users"? ;) > > Regards, > Paul > > > > -- > To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. >
Re: [PATCH] Basic WINGs theming
On 11/14/2013 08:00 PM, Carlos R. Mafra wrote: > People argue that "new users" will like to change widget colors in the > _future_. > I argue that old users don't care _now_. > Well, i am one of those old users, if not even one of the very old users of wmaker. I use it since at least since the year 2000, if not even earlier. There is even a changelog entry of the official Debian package of wmaker 0.91.0-5 from Fri, 07 Jan 2005 citing my name, while mentioning that i pointed to a patch by our estimated currrent list member Iain Patterson. Is this old enough? Time certainly flies. :) Being such an old user, i really wouldn't have minded already in the long gone _past_ if wmaker would finally be able to change widget colors in order to be more flexible while trying to create a more homogeneous desktop without having to subdue oneself to WINGs' color limitations. But i am repeating myself. :) At the very same time i defintely would very welcome those functional enhancements you mentioned in an earlier message within this thread, namely "a patch to implement resizing by dragging the corners or a patch to be able to navigate items in a list using the keyboard keys". And i would add things like copy and paste via keyboard shortcuts, which already wrote about in this list a few weeks/months ago. It would be great to have some kind of official TODO or roadmap containing these enhancement ideas officially published somewhere, in order to provide some guidance for interested developers. Yes, "changing the colors does not hurt either" is one way to put it, but i would rather express it as "enabling WINGs to be more flexible and adaptive" for those users who are trying to design a minimally homogeneous desktop in an absolutely heterogeneous world of Linux desktops and applications. We are in the 21st century now, not in 1995 anymore. In fact, as much as i would dislike a overturning revolution in wmaker, i definitely would not mind some more evolution in both functionality and design capabilities. I hope i still count as one of those "old users"? ;) Regards, Paul -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
a few thoughts / was: Re: [PATCH] Basic WINGs theming
Carlos: I guess it'd be better all around if you specified and published at least some of your priorities and anti-priorities. Also, set a procedure for cases when there's a conflict on what goes in and what doesn't. I sincerely commend you picking up the project maintenance when there was a dire need for that. And I do not care much for the new features alltogether. However, I can see, too, how folks could feel uncomfortable with your stance on the innovation. Nobody's really challenging your authority and your credits. Just that you sound a bit authoritarian here. Again, it's not what you say, it's more how you say it. Why not try to generate more positive feelings? *** W/r to the documentation, I'd say a potential user would initially want to know what one can do (do well) with WindowMaker. So, to enumerate some strong sides of WindowMaker as I see those: -is light-weight, instant start-up -has usable configuration out-of-the-box -has visual preferences editing application out-of-the-box -has visualised task switching out-of-the-box, unlike many (all?) WMs -has (rudimentary) visual launch list editing out-of-the-box (I mean launched apps leaving icons in dock) -has some stylish and recognisable UI design elements (checkboxes, dialogs' tabs' tabs, radiobuttons, balloons, titlebar) Big problems with WM: - grossly outdated concept of paths management (menu editor -> 'application to run' selector, icons/pixmap search paths ) - rough, unpolished look in some parts of the UI (fat scrollbars) - no transparent background for icons? in 2013? (yes, it might be emulated by setting screen background and icon background to be the same, but...) - some functional elements (theming elements selectors in main menu, 'run command' applet, window attributes inspector) feel half-done, even primitive -Yury On 11/14/2013 11:13 PM, Carlos R. Mafra wrote: ... -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On Thu, 14 Nov 2013 at 19:51:59 +, SJS wrote: > begin quoting Carlos R. Mafra as of Thu, Nov 14, 2013 at 07:00:08PM +: > > My point of view is that I want to please the current users, because > > they are _already_ using it due to its _current_ virtues. > [snip] > > People argue that "new users" will like to change widget colors in the > > _future_. > > I argue that old users don't care _now_. > > If, in chasing after new users, you make it so that you drive off the > old users, what do you gain? I think it's a bit of an exaggeration to say that having the option to change the WINGs color would drive off old users, but the idea is that we already like it the way it is, right? And there's always a small price to pay in terms of code size (I haven't checked in this case though), so that's why I think it's prudent to be on the conservative side by default. Small concessions here and there build up in the end. But as I said before the WINGs patch will be accepted, since it makes the code a bit more readable along the way (that's my attempt to look at the "half full glass"). At this point I think we could better chase new users by improving our documentation in the windowmaker.org site. It would be great if people with pedagogic and marketing abilities would devote some time to the content of our website. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
begin quoting Carlos R. Mafra as of Thu, Nov 14, 2013 at 07:00:08PM +: [chop] > Regarding the --replace patch I agree that there might be a few > users out there who could try wmaker for the first time using the --replace > scenario, but I don't think that is an argument why the log off & log > in procedure is not the simplest way to go. > > So there is a pretty straightforward way to use wmaker, just log in > to it. That's what we've always done, it's really simple. I'm not sure I understand the --replace option -- doesn't windowmaker already offer a way to easily try other window managers? There's a menu option for it. [snip] > My point of view is that I want to please the current users, because > they are _already_ using it due to its _current_ virtues. [snip] > People argue that "new users" will like to change widget colors in the > _future_. > I argue that old users don't care _now_. If, in chasing after new users, you make it so that you drive off the old users, what do you gain? -- Part of the Established Base. SJS -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On Thu, 14 Nov 2013 at 11:31:39 +, Iain Patterson wrote: > Quoth Rodolfo García Peñas (kix), > > >Carlos say what is included or not, he say who are commiters or not, > >and he say the wmaker destination. But, there are no rules. There are > >no method to know if a patch or a new idea will be included or not, > >there are not wmaker destination (we are solving problems, not > >improving wmaker). If I can't decide, I won't waste time writing code. > > I do think that we lack a clear focus with regards to project > direction. My point of view is to try to keep wmaker as it is now as hard as possible. I use wmaker because I like it as it is _now_, because of its simplicity. Since Rodolfo is complaining about me I guess I should not say this, but I need to in order to avoid misunderstandings: I don't care too much if we loose a possible user because he does not like how wmaker looks or because wmaker can't do this or that fancy thing. I don't care about software "democracy" either. I care about _current_ users, people who are here in the mailing list writing bug reports or just complaining about some issues. These are the people who decided to use wmaker because they thought it is worth it now, not because they are expecting some new feature some day. One nice thing about wmaker-crm is that by me being the sole committer I could have a way to cut off bloat and things which I don't personally feel are necessary. Regarding the --replace patch I agree that there might be a few users out there who could try wmaker for the first time using the --replace scenario, but I don't think that is an argument why the log off & log in procedure is not the simplest way to go. So there is a pretty straightforward way to use wmaker, just log in to it. That's what we've always done, it's really simple. I understand that Iain spent a lot of time with the patch, and that he is one of the most valuable contributors, but I couldn't change my mind about it. And don't forget that the prospecting users might try wmaker for the first time using --replace and go back to KDE or something. So we actually are wasting resources to a probability scenario. My point of view is that I want to please the current users, because they are _already_ using it due to its _current_ virtues. > > I don't have any objection to there being just one committer and I > don't have any objection to that one committer being Carlos. He's > shown himself to be motivated and capable and I get the impression > that he has a checklist that he considers before accepting patches - > correct formatting, no compiler warnings, update to the NEWS file - > which is exactly what you want from a committer. What I'm less sure > about, and what frustrates me as someone who's had patches > representing a substantial time investment rejected, is knowing what > that checklist actually is. Apart from bug fixes and code cleanups (which are accepted by default), the checklist is subjective. There is no way to guarrantee that a non-bug-fix patch will be accepted or not. The patch must be relevant to everyday usage in a clear way. The --replace and the WINGs theming patches are not that relevant. They will please a few users once or twice in a lifetime, perhaps a bit more, but the point is: who keeps changing the widget colors or trying new window managers from the terminal anyway?. Now compare that with the new maximization state patches. I (for example) use the left/right maximization _every_ single day, that's something that really matters. It affects productivity a lot in a meaningful way. People argue that "new users" will like to change widget colors in the _future_. I argue that old users don't care _now_. So the checklist is subjective but it has a point. Patches that can be used to increase productivity are probably accepted, patches that have no clear impact on productivity (or usage) and increase the number of lines of code are probably not going to be accepted. That's how I try to decide things but it's not always black & white. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: apropos dragging windows across workspaces / was: Re: [PATCH] Basic WINGs theming
Quoth Yury Tarasievich, How is such window dragging activated? I have fond memories of XView's multi-workspaces control and wouldn't mind having something similar in wmaker. It's in the Workspace preferences. "Switch workspaces while dragging windows." -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
apropos dragging windows across workspaces / was: Re: [PATCH] Basic WINGs theming
On 11/14/2013 02:31 PM, Iain Patterson wrote: ... Things which aid configurability. We're already very good at this. You can, for example, enable or disable dragging windows across workspaces and separately enable or disable magically creating workspaces when you do so. Perhaps there are other little things which some people like and other don't. ... I've read your comment and immediately thumbed through the appearance app tabs (current #next here). How is such window dragging activated? I have fond memories of XView's multi-workspaces control and wouldn't mind having something similar in wmaker. -Yury -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
Quoth Rodolfo García Peñas (kix), Carlos say what is included or not, he say who are commiters or not, and he say the wmaker destination. But, there are no rules. There are no method to know if a patch or a new idea will be included or not, there are not wmaker destination (we are solving problems, not improving wmaker). If I can't decide, I won't waste time writing code. I do think that we lack a clear focus with regards to project direction. I don't have any objection to there being just one committer and I don't have any objection to that one committer being Carlos. He's shown himself to be motivated and capable and I get the impression that he has a checklist that he considers before accepting patches - correct formatting, no compiler warnings, update to the NEWS file - which is exactly what you want from a committer. What I'm less sure about, and what frustrates me as someone who's had patches representing a substantial time investment rejected, is knowing what that checklist actually is. This whole debate has had somewhat of a polarising effect and with emotions running high it's all too easy to start viewing the development community in terms of two camps, the conservatives who are only interested in bug fixes and code cleanup, and the progressives who want to commit anything that compiles. The reality isn't like that. We've added lots of features to wmaker-crm, drawers being only the most recent, and even among the patches which have been rejected there haven't been any outlandish ideas; no one is proposing that wmaker needs a builtin flight simulator. It's a small project. Too small to leave any of the (very few) developers feeling like their contributions aren't welcome. Let's decide what we want wmaker to be before we start talking about forks. In terms of the direction that I'd like to see... Bug fixes, code tidyup, optimisations etc of course. We're good at this already. Features which enable new users to discover wmaker. My --replace patch was written with that in mind. If an XFCE user has heard of wmaker and wants to try it out, it's a lot easier to say "type wmaker --replace at the command line then xfwm4 --replace to go back" than "so first you need to identify and kill your existing window manager process..." or worse "just close down all your applications and log out..." Yes I would consider theming or eye candy features to be in this category. Users like good looking desktops. Features from other desktops. If another window manager does something well then surely there's no shame in "copying" that feature. Things which aid configurability. We're already very good at this. You can, for example, enable or disable dragging windows across workspaces and separately enable or disable magically creating workspaces when you do so. Perhaps there are other little things which some people like and other don't. New features should be configurable where appropriate. It doesn't make a lot of sense for the --replace feature to be disabled but the "start typing in the switchpanel to match window titles" patch I submitted did have an option to completely disable its functionality. We tend to be good at this already. Where a new feature would change the behaviour of some existing system it should be disabled by default so that a user who didn't explicitly enable it would see no change. We're good at this already. I'm quite happy to see some kind of peer review regarding patches that don't obviously fit within whichever guidelines we agree on. That could be a vote or a challenge to make a convincing arguement for it or something else. And probably some other stuff I forgot. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On 14-11-2013 07:31, Rodolfo García Peñas (kix) wrote: > Hi, > > Sorry for the delay. I am too busy this week. I have a lot of work. > > I am talking about different hats: > > 1. Developer hat > 2. Commiter hat > > *All* developers have the same weight, and they can disscuss about what > patches should be uploaded or not. > The commiter only do the commit. IMO the current behavior is that Carlos > say what is included or not, he say who are commiters or not, and he say > the wmaker destination. But, there are no rules. There are no method to > know if a patch or a new idea will be included or not, there are not > wmaker destination (we are solving problems, not improving wmaker). If I > can't decide, I won't waste time writing code. > > I don't want to continue with this discussion more time, but I don't > like the current method. Some tips IMO: > > 1. We should search a new place with integrated git+BTS+code review (I > don't know if github or other place could do it). I have a lot of things > here, in my paper-notepad, about wmaker. I would like to upload them to > an stable BTS as bugs/wishlist. Why I don't like repo.or.cz? Because we > don't have BTS, and because the current behavior doesn't include code > review (we don't discuss about the patches in the mail list), so I (we) > cannot decide about patches. If something is in the repo then it exist, > else, the thing (patch, idea) never happended. > > 2. Rules. Rules about what the commiter can do, what can do the > developers. Definitions about what is a developer, what is a > commiter,... I would like know what I am doing here. If the commiter has > more weight than developers and there are only one commiter, we have a > problem. > > 3. Flexibility to do things and branch definitions. I have experimiental > branches here about new ideas. I sent some patches twice, but the code > is only in the mail list, so nobody can help. I would like to make > commits in expermimental branches and the code could be included in the > #next branch. The current branching method is a binany method. Or the > patch is included, or the patch is not included. Patches should be > stable, solve bugs. The #next branch is only a pre-master branch, so IMO > there are no differences between #master and #next (only, some time). > > 4. Future. Where we are going? Then, where can we write our ideas, our > plan? As a user, I would like to vote to have wmaker on a better place (github ?) with a bug tracker. It improves a lot the visibility (for users) of what is happening with the project. Most of opensource projects have a place to fill a bug or feature request, I believe users and wmaker would benefit of this and would help much more to report issues and test solutions. -- Renato Botelho -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
Hi, Sorry for the delay. I am too busy this week. I have a lot of work. I am talking about different hats: 1. Developer hat 2. Commiter hat *All* developers have the same weight, and they can disscuss about what patches should be uploaded or not. The commiter only do the commit. IMO the current behavior is that Carlos say what is included or not, he say who are commiters or not, and he say the wmaker destination. But, there are no rules. There are no method to know if a patch or a new idea will be included or not, there are not wmaker destination (we are solving problems, not improving wmaker). If I can't decide, I won't waste time writing code. I don't want to continue with this discussion more time, but I don't like the current method. Some tips IMO: 1. We should search a new place with integrated git+BTS+code review (I don't know if github or other place could do it). I have a lot of things here, in my paper-notepad, about wmaker. I would like to upload them to an stable BTS as bugs/wishlist. Why I don't like repo.or.cz? Because we don't have BTS, and because the current behavior doesn't include code review (we don't discuss about the patches in the mail list), so I (we) cannot decide about patches. If something is in the repo then it exist, else, the thing (patch, idea) never happended. 2. Rules. Rules about what the commiter can do, what can do the developers. Definitions about what is a developer, what is a commiter,... I would like know what I am doing here. If the commiter has more weight than developers and there are only one commiter, we have a problem. 3. Flexibility to do things and branch definitions. I have experimiental branches here about new ideas. I sent some patches twice, but the code is only in the mail list, so nobody can help. I would like to make commits in expermimental branches and the code could be included in the #next branch. The current branching method is a binany method. Or the patch is included, or the patch is not included. Patches should be stable, solve bugs. The #next branch is only a pre-master branch, so IMO there are no differences between #master and #next (only, some time). 4. Future. Where we are going? Then, where can we write our ideas, our plan? kix "Carlos R. Mafra" escribió: On Mon, 11 Nov 2013 at 9:32:04 +0300, Yury Tarasievich wrote: I think we have the gist of the problem right there, in the lines quoted. I see a plain clash of perspectives there. We *might* benefit from the new ideas, generated in the way of hobbie or otherwise. We *would* benefit from general production going forward. I won't go so far as to declare the "production manager" some sort of supreme authority. However, it is obvious that not every idea is bound to make it into the (long-existing) software product, for which PM is, after all, responsible. So I'd say there's an *urgent* need for some kind of contribution rejection procedure. Something like following: (a) Carlos (or anybody) with his PM's hat on has the first (immediate) say on what is *not* going in *right now*. (b) However, there also must be an (almost immediate) request for comments going into the list, formal-like. (c) If the request gathers no evidence supporting the innovation, everything stays as it was. (d) Otherwise, steps are taken etc. I believe this is simple enough and sufficient to block (or alleviate) the rise of bad feelings. But this is what happens already, and this thread illustrates that. My first reaction to the theming patch is that we don't need it. The patch is good etc, but the idea behind the patch leads to bloat. My opinion is that not everything that can be done should be done. Bloat starts like this: "wouldn't it be cool if...?" and then you make a small concession because many people appear on the mailing list and say "yes, it is cool, please do it. It doesn't increase the size too much." So in this case, despite the patch being OK I felt the need to stop the idea. Keep the WINGs widgets as simple as possible, no choice of colors whatsoever etc. That is what it has been for the past +15 years already and no one is suddenly going to dislike WM because the widgets cannot be green or red. But given the reaction, I am "forced" to accept the patch. There has even been a suggestion to fork wmaker! And perhaps I'm being too conservative, so it will be OK in the end. But in any case, if the repository was only mine the patch would not go in. So the above situation corresponds to your steps a) - d) above. What I guess it's happening here is that Rodolfo is complaining not because of other people's patches, but because his own patches have a history of a rough ride into the repository. Not everything he codes I like 100% (I have the impression that he was learning how to code along the way last year or so), so sometimes there are clashes and he is fed up. He has a 40-patch series that is not applied yet, and I'm not sure what to do. -- To unsubscribe, send mail to wmaker-dev-
Re: [PATCH] Basic WINGs theming
On Mon, 11 Nov 2013 at 17:25:44 +0300, Yury Tarasievich wrote: > > Having said that, the code bloat is bad, but the look artificially > left back in the "20 years ago" epoch might be not-so-good, too. > About the only *visual* feature of the *WINGs* I like are those > clever checkboxes; radiobuttons are not bad. Overall, the *visual* > impression isn't so much of "aged product", as of unpolished, > rough-from-the-workbench thing. BTW, the option of modifying the > standard "colors" themselves would be of no relevance here, without > more extensive rethink (of layout, geometry, proportions etc.). I would love a patch to implement resizing by dragging the corners or a patch to be able to navigate items in a list using the keyboard keys and things like that. These are the kind of improvements that I think are most relevant. But changing the colors does not hurt either, so why not. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On 11/11/2013 01:09 PM, Carlos R. Mafra wrote: On Mon, 11 Nov 2013 at 9:32:04 +0300, Yury Tarasievich wrote: ... So I'd say there's an *urgent* need for some kind of contribution rejection procedure. Something like following: (a) Carlos (or anybody) with his PM's hat on has the first (immediate) say on what is *not* going in *right now*. (b) However, there also must be an (almost immediate) request for comments going into the list, formal-like. (c) If the request gathers no evidence supporting the innovation, everything stays as it was. (d) Otherwise, steps are taken etc. ... So in this case, despite the patch being OK I felt the need to stop the idea. Keep the WINGs widgets as simple as ... But given the reaction, I am "forced" to accept the patch. There has even been a suggestion to fork wmaker! And perhaps I'm being too conservative, so it will be OK in the end. But in any case, if the repository was only mine the patch would not go in. So the above situation corresponds to your steps a) - d) above. Not exactly, as I see it. There was no formal rejection (was there?), no issuing the "formal" RRFC (Rejection Request for Comments), and so the ensuing discussion was mostly heated by hurt feelings in the unclear context. I believe it's just this lack of a bit of formal procedure which made way for the unpleasantness. (And of course the (c) step must generate some definitely positive support, not lazy lack of opposition). *** Having said that, the code bloat is bad, but the look artificially left back in the "20 years ago" epoch might be not-so-good, too. About the only *visual* feature of the *WINGs* I like are those clever checkboxes; radiobuttons are not bad. Overall, the *visual* impression isn't so much of "aged product", as of unpolished, rough-from-the-workbench thing. BTW, the option of modifying the standard "colors" themselves would be of no relevance here, without more extensive rethink (of layout, geometry, proportions etc.). -Yury -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On Mon, 11 Nov 2013 at 9:32:04 +0300, Yury Tarasievich wrote: > I think we have the gist of the problem right there, in the lines > quoted. I see a plain clash of perspectives there. > > We *might* benefit from the new ideas, generated in the way of > hobbie or otherwise. > We *would* benefit from general production going forward. > > I won't go so far as to declare the "production manager" some sort > of supreme authority. However, it is obvious that not every idea is > bound to make it into the (long-existing) software product, for > which PM is, after all, responsible. > > So I'd say there's an *urgent* need for some kind of contribution > rejection procedure. Something like following: (a) Carlos (or > anybody) with his PM's hat on has the first (immediate) say on what > is *not* going in *right now*. (b) However, there also must be an > (almost immediate) request for comments going into the list, > formal-like. (c) If the request gathers no evidence supporting the > innovation, everything stays as it was. (d) Otherwise, steps are > taken etc. > > I believe this is simple enough and sufficient to block (or > alleviate) the rise of bad feelings. But this is what happens already, and this thread illustrates that. My first reaction to the theming patch is that we don't need it. The patch is good etc, but the idea behind the patch leads to bloat. My opinion is that not everything that can be done should be done. Bloat starts like this: "wouldn't it be cool if...?" and then you make a small concession because many people appear on the mailing list and say "yes, it is cool, please do it. It doesn't increase the size too much." So in this case, despite the patch being OK I felt the need to stop the idea. Keep the WINGs widgets as simple as possible, no choice of colors whatsoever etc. That is what it has been for the past +15 years already and no one is suddenly going to dislike WM because the widgets cannot be green or red. But given the reaction, I am "forced" to accept the patch. There has even been a suggestion to fork wmaker! And perhaps I'm being too conservative, so it will be OK in the end. But in any case, if the repository was only mine the patch would not go in. So the above situation corresponds to your steps a) - d) above. What I guess it's happening here is that Rodolfo is complaining not because of other people's patches, but because his own patches have a history of a rough ride into the repository. Not everything he codes I like 100% (I have the impression that he was learning how to code along the way last year or so), so sometimes there are clashes and he is fed up. He has a 40-patch series that is not applied yet, and I'm not sure what to do. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
I think we have the gist of the problem right there, in the lines quoted. I see a plain clash of perspectives there. We *might* benefit from the new ideas, generated in the way of hobbie or otherwise. We *would* benefit from general production going forward. I won't go so far as to declare the "production manager" some sort of supreme authority. However, it is obvious that not every idea is bound to make it into the (long-existing) software product, for which PM is, after all, responsible. So I'd say there's an *urgent* need for some kind of contribution rejection procedure. Something like following: (a) Carlos (or anybody) with his PM's hat on has the first (immediate) say on what is *not* going in *right now*. (b) However, there also must be an (almost immediate) request for comments going into the list, formal-like. (c) If the request gathers no evidence supporting the innovation, everything stays as it was. (d) Otherwise, steps are taken etc. I believe this is simple enough and sufficient to block (or alleviate) the rise of bad feelings. And do not bother with forks, multiply repos etc., that's silly. There is no enough of human resource here as it is. -Yury On 11/11/2013 02:38 AM, "Rodolfo García Peñas (kix)" wrote: On 10/11/2013 23:32, Carlos R. Mafra wrote: ... So, what is the problem? For me wmaker is a hobbie. I spent a lot of time writting patches, thinking about new ideas. Sometimes I make ... -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On 10/11/2013 23:32, Carlos R. Mafra wrote: > > On Sat, 9 Nov 2013 at 23:43:35 +0100, Rodolfo García Peñas (kix) wrote: >> >> >> "Carlos R. Mafra" escribió: >> >>> On Sat, 9 Nov 2013 at 21:55:16 +, Rodolfo García Peñas (kix) >>> wrote: "Carlos R. Mafra" escribió: > On Sat, 9 Nov 2013 at 19:19:21 +, Rodolfo García Peñas (kix) >>> wrote: >> >> The question is: "Could you accept a patch in the git that you >>> don't >> agree with?" > > Yes. > Thanks, and about this question: ->> You're talking about forcing him to discard his aesthetic? -> The question is, is their project or is our project? -> If wmaker is their project, he can do everyting. If is our -> project, perhaps he should hear us. Please, choose, is our or >>> yours? >>> >>> http://en.wikipedia.org/wiki/False_dilemma >> >> Why? Should I split the questions? >> >> Is yours or our? > > You are trying to create an artificial separation where there is none. > Why do you want to exclude me from your "our"? That is not true. I don't want to exclude you from the "our". This is not a personal attack to you. As I said, you are doing a good work with window maker. Is very difficult for me explain some things in english. So, what is the problem? For me wmaker is a hobbie. I spent a lot of time writting patches, thinking about new ideas. Sometimes I make mistakes and you request me some changes in my patches, and that is perfect. But, IMO, you cannot drop a patch only because you don't agree with. I am not working for you, I am working for the wmaker project, for the users. If you say what is accepted or not, without ask more people, developers; If only you take the decission about what is included or not, then wmaker is your project, and I won't contribute on it. > >>> Finally, what do you think about add more commiters to wmaker and dockapps repo? >>> >>> A bad idea. >> >> Why? > > I believe there must be only one person with the final word, otherwise > discussions and disagreements will generate tensions and they will > have to be resolved by political means. That is your point of view. If I sent patches and you drop them, it will create tensions between us. If you think that a patch shouldn't be included, you ask about it to the developers, and they say that the patch is ok, you should include it, but if the developers say "no", I can understand that I did a wrong patch. > I try to listen to other people and I change my mind too. For example, my > first reaction to the WINGs theming patch was that we don't need this. Yes. After some mails. And about this? http://www.mail-archive.com/wmaker-dev@lists.windowmaker.org/msg03294.html Why it should be a configure option or a DEBUG option? (I don't want the reply). Other developer said that the patch is ok, and for me. But your decission had more weight. > But the patch makes the code a bit cleaner too, other people seemed > to like the idea and there is no impact in the code. I still think it's > not useful to change the look of the widgets, but I'm going to accept > the patch nevertheless. > > See? That should have answered your question about whether I accept > things that I don't "agree" or rather, that I don't like. > > But nothing seem to matter to you anymore, you already proposed to fork > because you find unacceptable to have only one commiter (I wonder > what you think about the linux kernel and its single commiter). The problem is not that we have only one commiter. I don't want to be a commiter, is a terrible work. The problem is that only you, take the decissions about what can be uploaded or not. IMO: - Developers -> write patches and give the opinion about patches. - Commiter -> upload the patches that the developers accepts. IMO, in a democratic idea, the commiter only upload patches. The decission is done by the developers. Of course, the commiter probably is a developer and can give the oppinion, but is only one developer more. See this image about code review (gerrit) http://aniszczyk.org/wp-content/uploads/2011/08/gerrit.png The people can vote the patches. > Let me ask you. From the past couple of years of development what would > _you_ have done differently? How many patches of disagreement are motivating > you to create a fork? I don't want to create a fork, but I cannot accept that only you take the decissions about my work. I can accept that my patches won't be uploaded if the developer team say no, but not only you, because is my hobbie time. -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On Sat, 9 Nov 2013 at 23:43:35 +0100, Rodolfo García Peñas (kix) wrote: > > > "Carlos R. Mafra" escribió: > > >On Sat, 9 Nov 2013 at 21:55:16 +, Rodolfo García Peñas (kix) > >wrote: > >> > >> "Carlos R. Mafra" escribió: > >> > >> >On Sat, 9 Nov 2013 at 19:19:21 +, Rodolfo García Peñas (kix) > >wrote: > >> >> > >> >>The question is: "Could you accept a patch in the git that you > >don't > >> >>agree with?" > >> > > >> >Yes. > >> > > >> > >> Thanks, > >> > >> and about this question: > >> > >> ->> You're talking about forcing him to discard his aesthetic? > >> -> The question is, is their project or is our project? > >> -> If wmaker is their project, he can do everyting. If is our > >> -> project, perhaps he should hear us. Please, choose, is our or > >yours? > > > >http://en.wikipedia.org/wiki/False_dilemma > > Why? Should I split the questions? > > Is yours or our? You are trying to create an artificial separation where there is none. Why do you want to exclude me from your "our"? >> Finally, what do you think about add more commiters to wmaker and > >> dockapps repo? > > > >A bad idea. > > Why? I believe there must be only one person with the final word, otherwise discussions and disagreements will generate tensions and they will have to be resolved by political means. I try to listen to other people and I change my mind too. For example, my first reaction to the WINGs theming patch was that we don't need this. But the patch makes the code a bit cleaner too, other people seemed to like the idea and there is no impact in the code. I still think it's not useful to change the look of the widgets, but I'm going to accept the patch nevertheless. See? That should have answered your question about whether I accept things that I don't "agree" or rather, that I don't like. But nothing seem to matter to you anymore, you already proposed to fork because you find unacceptable to have only one commiter (I wonder what you think about the linux kernel and its single commiter). Let me ask you. From the past couple of years of development what would _you_ have done differently? How many patches of disagreement are motivating you to create a fork? -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: New fork? Was: Re: [PATCH] Basic WINGs theming
On Nov 10, 2013, at 6:58 PM, Rodolfo García Peñas wrote:
> Thanks again for your reply.
>
> As you can see in their last mail, about the idea of include more commiters
> ("Bad idea"), things doesn't change too much. For me is unacceptable.
>
> If more people thinks that is good moment to make a fork and create a new
> repo with more than one commiter, more democratic, I will collaborate in the
> new fork.
I see one big problem with that: based on the mailing list activity, you are
going to be the only regular committer to that fork. A few people delivering
patches sporadically count just as much as they count right now (and you are
the only so far to propose a fork at all).
What is really undesirable is that it sounds very much like it’s going to be a
hostile fork. Hostile forks by a single person are really ephemeral, the
history tells us. And a „more democratic” process only means a thing if there
are at least a few people whose really useful contributions were rejected.
Can you please name those people? Can you please also list the really useful
patches that have been rejected beyond hope of ever being accepted?
There was a fork of CNOME called GoneME around GNOME 2.8 (back in 2004). [1]
It’s quite a good illustration of how forks that are started out of annoyance,
die. Mind you, the author managed to make quite a buzz[2] and there were people
willing to help (initially). I fail to see annoyed crowds here, so it’s safe to
predict that a fork would die in, say, a month, after its author’s enthusiasm
vanishes.
What *can* be done, though, is a fork in a sense of a Github fork. That is,
your repository with all your cool ideas goes public, and so does the process
around it. Issues get filed and tracked, people do more forks to test their
ideas on, there are pull requests, which after a few stabilising rounds go
upstream, that is, here. Call it a „friendly fork“ or something like that, so
there is still a single project at the core, and there is NO bloody „Rodolfo
vs. Carlos“, or, for that matter, „Anyone vs. Carlos“, stanza in it.[3]
I can see a good thing in it that so far WindowMaker so far doesn’t have a real
public bug tracker, it should really grow one. Also, it would keep code reviews
consolidated, so you could easily see there are reasons for not accepting a
patch right away.
Also, I hope it gives you a gist of understanding that „democracy“ doesn’t
quite work in software projects, especially after you yourself reject a few
pull requests which don’t add (or subtract) value and get an angry reply from
someone who spent their precious time on it.
I’m sorry for jumping in with such a long-winded reply, having not contributed
a single line of code to WM. It’s just that I care for this project too much to
see it killed.
[1] http://www.akcaagac.com/index_goneme.html
[2]
http://tech.slashdot.org/story/04/07/25/144244/project-goneme-fixes-perceived-gnome-ui-errors
[3] What the actual hell. repo.or.cz allows forking repos. Why not? However, it
doesn’t have issue tracker and a nice UI for pull requests.
Re: [PATCH] Basic WINGs theming
"Carlos R. Mafra" escribió: >On Sat, 9 Nov 2013 at 21:55:16 +, Rodolfo García Peñas (kix) >wrote: >> >> "Carlos R. Mafra" escribió: >> >> >On Sat, 9 Nov 2013 at 19:19:21 +, Rodolfo García Peñas (kix) >wrote: >> >> >> >>The question is: "Could you accept a patch in the git that you >don't >> >>agree with?" >> > >> >Yes. >> > >> >> Thanks, >> >> and about this question: >> >> ->> You're talking about forcing him to discard his aesthetic? >> -> The question is, is their project or is our project? >> -> If wmaker is their project, he can do everyting. If is our >> -> project, perhaps he should hear us. Please, choose, is our or >yours? > >http://en.wikipedia.org/wiki/False_dilemma Why? Should I split the questions? Is yours or our? >> Finally, what do you think about add more commiters to wmaker and >> dockapps repo? > >A bad idea. Why? -- Enviado desde mi teléfono con K-9 Mail. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
New fork? Was: Re: [PATCH] Basic WINGs theming
Thanks again for your reply.
As you can see in their last mail, about the idea of include more commiters
("Bad idea"), things doesn't change too much. For me is unacceptable.
If more people thinks that is good moment to make a fork and create a new repo
with more than one commiter, more democratic, I will collaborate in the new
fork.
Cheers,
kix
On Sat, 09 Nov 2013, SJS escribió:
> (Apologies to John, once again. I need a round tuit...)
>
> begin quoting Rodolfo Garc??a Pe??as (kix) as of Sat, Nov 09, 2013 at
> 05:13:17PM +:
> [chop]
> >> The edge is based on the aesthetic sensibilities of the curator; better
> >> arguments are the way to change the edge, not the tyranny of the majority.
> >
> > But, if the arguments of the majority are dropped, could we talk about
> > the tyranny of the curator?
>
> In an open-source world? Not really. The code is all there, if the
> majority really find the curator to be unacceptable, they'll fork.
> If the fork attempt fails, the majority isn't as major as they thought,
> or the curator wasn't as off-base as was believed.
>
> So there isn't any tyranny of a curator, as if the majority back the curator,
> it's not a tyranny, and if they don't, they follow the fork, and again, no
> tyranny.
>
> The more interesting thing to discuss is: "What problem do you have
> with the aesthetic of the curator?"
>
> >> If you're not going to have a small team handle the duties and argue
> >> among themselves, then you've got to rely on a single curator.
> >
> > Perhaps the small team is not invited to handle the duties.
>
> How big is the team for *BSDs or the Linux kernel, compared to the
> contributing base?
>
> I don't think WindowMaker has enough players to handle having a
> small team of curators, without crippling development.
>
> >> You can always fork the repo and run it yourself in parallel. That's the
> >> ultimate open-source solution to "I'm unhappy with the curation of
> >> $project."
> >
> > Yes, but this is the argument of the children that has the game and
> > set the rules. My game, my rules.
>
> It's also the fundamental argument for security: your systems, your rules.
> Not all lessons learned as children are bad. :)
>
> > There are a lot of project and forks for this reason. Many
> > applications to do the same. Is bad be a little bit open?
>
> It is not quite a bit open? Anyone can suggest a patch. Chances are, changes
> will make it into the codebase.
>
> The problem does not appear to be openness, but with standards and cadence;
> not all changes are accepted at first acceptance, and may require a couple of
> iterations before they're deemed be be 'up to snuff' and applied, and the time
> between the submission and the ultimate acceptance can be slightly longer than
> some people wish for.
>
> I have never seen a patch rejected without a reason, and the reasons that I
> have read have always seem, well, reasonable. Voting to overrule a reasonable
> objection in order to speed things up strikes me as unwise.
>
> Patience is not well served by the hammer of democracy.
>
> [chop]
> >>> I know what you said. But, why (only) you can say what is accepted or
> >>> not? Could you accept a patch in the git that you don't agree with?
> >>
> >> You're talking about forcing him to discard his aesthetic?
> >
> > The question is, is their project or is our project? If wmaker is
> > their project, he can do everyting. If is our project, perhaps he
> > should hear us. Please, choose, is our or yours? That is important for
> > me. And the previous question was not replied, could you accept that
> > patch?
>
> I don't agree with your perspective.
>
> Do you want a curator or an integrator? A curator has opinions and
> sensibilities based on experience and talent, and a big part of the
> job is applying those. You trust the curator to do the Right Thing.
>
> An integrator is just someone who has the task of orderly incorporating
> changes and somehow making it work well enough to gain acceptance.
>
> If you want a curator, delegate the responsibility and either abide
> by the decisions they make, or find a new curator.
>
> If you want an integrator, pay them a salary.
>
> I do not see the trust misplaced. I *do* have a problem of talking about
> a curator being _forced_ (in theory) to accept a change they object to,
> rather than having a discussion that teases out and clarifies the actual
> issues, so they can be addressed in the open, and either the curator's
> mind changed by discussion, or the proposed change modified to address
> the objections.
>
> Committees make poor engineering decisions.
>
> --
> SJS
>
>
> --
> To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
--
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
(Apologies to John, once again. I need a round tuit...) begin quoting Rodolfo Garc??a Pe??as (kix) as of Sat, Nov 09, 2013 at 05:13:17PM +: [chop] >> The edge is based on the aesthetic sensibilities of the curator; better >> arguments are the way to change the edge, not the tyranny of the majority. > > But, if the arguments of the majority are dropped, could we talk about > the tyranny of the curator? In an open-source world? Not really. The code is all there, if the majority really find the curator to be unacceptable, they'll fork. If the fork attempt fails, the majority isn't as major as they thought, or the curator wasn't as off-base as was believed. So there isn't any tyranny of a curator, as if the majority back the curator, it's not a tyranny, and if they don't, they follow the fork, and again, no tyranny. The more interesting thing to discuss is: "What problem do you have with the aesthetic of the curator?" >> If you're not going to have a small team handle the duties and argue >> among themselves, then you've got to rely on a single curator. > > Perhaps the small team is not invited to handle the duties. How big is the team for *BSDs or the Linux kernel, compared to the contributing base? I don't think WindowMaker has enough players to handle having a small team of curators, without crippling development. >> You can always fork the repo and run it yourself in parallel. That's the >> ultimate open-source solution to "I'm unhappy with the curation of $project." > > Yes, but this is the argument of the children that has the game and > set the rules. My game, my rules. It's also the fundamental argument for security: your systems, your rules. Not all lessons learned as children are bad. :) > There are a lot of project and forks for this reason. Many > applications to do the same. Is bad be a little bit open? It is not quite a bit open? Anyone can suggest a patch. Chances are, changes will make it into the codebase. The problem does not appear to be openness, but with standards and cadence; not all changes are accepted at first acceptance, and may require a couple of iterations before they're deemed be be 'up to snuff' and applied, and the time between the submission and the ultimate acceptance can be slightly longer than some people wish for. I have never seen a patch rejected without a reason, and the reasons that I have read have always seem, well, reasonable. Voting to overrule a reasonable objection in order to speed things up strikes me as unwise. Patience is not well served by the hammer of democracy. [chop] >>> I know what you said. But, why (only) you can say what is accepted or >>> not? Could you accept a patch in the git that you don't agree with? >> >> You're talking about forcing him to discard his aesthetic? > > The question is, is their project or is our project? If wmaker is > their project, he can do everyting. If is our project, perhaps he > should hear us. Please, choose, is our or yours? That is important for > me. And the previous question was not replied, could you accept that > patch? I don't agree with your perspective. Do you want a curator or an integrator? A curator has opinions and sensibilities based on experience and talent, and a big part of the job is applying those. You trust the curator to do the Right Thing. An integrator is just someone who has the task of orderly incorporating changes and somehow making it work well enough to gain acceptance. If you want a curator, delegate the responsibility and either abide by the decisions they make, or find a new curator. If you want an integrator, pay them a salary. I do not see the trust misplaced. I *do* have a problem of talking about a curator being _forced_ (in theory) to accept a change they object to, rather than having a discussion that teases out and clarifies the actual issues, so they can be addressed in the open, and either the curator's mind changed by discussion, or the proposed change modified to address the objections. Committees make poor engineering decisions. -- SJS -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On Sat, 9 Nov 2013 at 21:55:16 +, Rodolfo García Peñas (kix) wrote: > > "Carlos R. Mafra" escribió: > > >On Sat, 9 Nov 2013 at 19:19:21 +, Rodolfo García Peñas (kix) wrote: > >> > >>The question is: "Could you accept a patch in the git that you don't > >>agree with?" > > > >Yes. > > > > Thanks, > > and about this question: > > ->> You're talking about forcing him to discard his aesthetic? > -> The question is, is their project or is our project? > -> If wmaker is their project, he can do everyting. If is our > -> project, perhaps he should hear us. Please, choose, is our or yours? http://en.wikipedia.org/wiki/False_dilemma > Finally, what do you think about add more commiters to wmaker and > dockapps repo? A bad idea. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
"Carlos R. Mafra" escribió: On Sat, 9 Nov 2013 at 19:19:21 +, Rodolfo García Peñas (kix) wrote: The question is: "Could you accept a patch in the git that you don't agree with?" Yes. Thanks, and about this question: ->> You're talking about forcing him to discard his aesthetic? -> The question is, is their project or is our project? -> If wmaker is their project, he can do everyting. If is our -> project, perhaps he should hear us. Please, choose, is our or yours? Finally, what do you think about add more commiters to wmaker and dockapps repo? kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On Sat, 9 Nov 2013 at 19:19:21 +, Rodolfo García Peñas (kix) wrote: > > The question is: "Could you accept a patch in the git that you don't > agree with?" Yes. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
Yaroslav Fedevych escribió: On Nov 9, 2013, at 6:24 PM, Carlos R. Mafra wrote: On Sat, 9 Nov 2013 at 17:13:17 +, Rodolfo García Peñas (kix) wrote: And the previous question was not replied, could you accept that patch? Yes, the patch will be accepted. But he is currently working in a new version of it to address some comments. I don't understand why the rush here. People just are being worried and afraid. :-) No. The people is making questions and the questions are not answered. "Staying true to NeXTStep foundations", some worry, is a sure way to make WM nothing more than a museum exhibit — something we all better avoid, because WM (fortunately!) is a real piece of software used by real people for real work. I personally hope I won’t need to compare WindowMaker to Lenin’s body in its tomb for the next 40 years or so. So when there is a prolonged silence in response to a patch, or an idea, rumours start circulating, it’s kinda inevitable. Humans being humans. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
"Carlos R. Mafra" escribió: On Sat, 9 Nov 2013 at 17:13:17 +, Rodolfo García Peñas (kix) wrote: And the previous question was not replied, could you accept that patch? Yes, the patch will be accepted. But he is currently working in a new version of it to address some comments. I don't understand why the rush here. Because I was talking about this question, not about the patch: -> And in this particular case you mention I said the patch would be -> accepted if it was not compiled by default. -> I know what you said. But, why (only) you can say what is accepted or -> not? Could you accept a patch in the git that you don't agree with? The question is: "Could you accept a patch in the git that you don't agree with?" Of course, with the patch with rigth comments, code style,... Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On Nov 9, 2013, at 6:24 PM, Carlos R. Mafra wrote: > On Sat, 9 Nov 2013 at 17:13:17 +, Rodolfo García Peñas (kix) wrote: >> >> And the previous question was not replied, could you accept that >> patch? > > Yes, the patch will be accepted. But he is currently working in a > new version of it to address some comments. > > I don't understand why the rush here. People just are being worried and afraid. :-) "Staying true to NeXTStep foundations", some worry, is a sure way to make WM nothing more than a museum exhibit — something we all better avoid, because WM (fortunately!) is a real piece of software used by real people for real work. I personally hope I won’t need to compare WindowMaker to Lenin’s body in its tomb for the next 40 years or so. So when there is a prolonged silence in response to a patch, or an idea, rumours start circulating, it’s kinda inevitable. Humans being humans. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On Sat, 9 Nov 2013 at 17:13:17 +, Rodolfo García Peñas (kix) wrote: > > And the previous question was not replied, could you accept that > patch? Yes, the patch will be accepted. But he is currently working in a new version of it to address some comments. I don't understand why the rush here. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
SJS escribió: Thanks for your comments, [chop] > It is just me being conservative and trying to tell people what I think > comes close to the edge of acceptance. Who set the edge? Can more people change the edge? The edge is based on the aesthetic sensibilities of the curator; better arguments are the way to change the edge, not the tyranny of the majority. But, if the arguments of the majority are dropped, could we talk about the tyranny of the curator? If you're not going to have a small team handle the duties and argue among themselves, then you've got to rely on a single curator. Perhaps the small team is not invited to handle the duties. You can always fork the repo and run it yourself in parallel. That's the ultimate open-source solution to "I'm unhappy with the curation of $project." Yes, but this is the argument of the children that has the game and set the rules. My game, my rules. There are a lot of project and forks for this reason. Many applications to do the same. Is bad be a little bit open? [snip] > And in this particular case you mention I said the patch would be > accepted if it was not compiled by default. I know what you said. But, why (only) you can say what is accepted or not? Could you accept a patch in the git that you don't agree with? You're talking about forcing him to discard his aesthetic? The question is, is their project or is our project? If wmaker is their project, he can do everyting. If is our project, perhaps he should hear us. Please, choose, is our or yours? That is important for me. And the previous question was not replied, could you accept that patch? kix -- SJS -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
RE: [PATCH] Basic WINGs theming
> From: Christophe [mailto:christophe.cu...@free.fr] > [snip] > Thanks, Christophe! I really appreciate all the comments and ideas. I hope to submit a new version of the patch with lots of improvements in the next week or so. Doug
Re: [PATCH] Basic WINGs theming
- Douglas Torrance a écrit :
> On 11/05/2013 05:58 PM, Christophe wrote:
> > Although I do like the idea brought by the patch, there are a few things in
> > this implementation that I would suggest to do differently:
>
> Absolutely! I'm a mathematician, not a programmer, so I appreciate all
> the input I can get!
>
> >> +WMTheme* W_GetTheme(WMScreen *scr);
> > I think this should appear in the visible API of the toolkit.
> > A theme is something internal to the toolkit, the application using it
> > should not see it
> >
> I'm a little confused here. Are you suggesting that themes should be
> visible or not? Also, what determines this? Is it WINGs.h vs.
> WINGsP.h? I couldn't find any documentation on what goes where, so I
> just tried to follow the example of what was already there.
It not really documented yet (although I have some patches ideas to make it
more clear in the future), but the info you need is:
- WINGs.h is the public API of the toolkit, which should be touched with care
for compatibility and consistency;
- WINGsP.h is an internal header to WINGs (P=Private)
On the topic of what should be private or public, my point of view is:
- the theme structure itself should be public, because applications often need
to create custom widgets so they need theses colors for consistency (that is
currently done through the not so great white/black/gray/... that you pointed
out;
- the theme loading and handling should be private, because it is the
responsibility of the toolkit to take care of this, not of the application (and
it also reduces the risk of breaking compatibility with old apps)
> >> +typedef struct WMTheme {
> >> + WMColor *background;
> >> + WMColor *foreground;
> >> + WMColor *shadow;
> >> + WMColor *highlight;
> >> + WMColor *unselectedTabBackground;
> >> + WMColor *unselectedTabHighlight;
> >> +} WMTheme;
> > I would suggest to rethink the names and organisation of this structure,
> > because there will need more, for example: background is for what? the
> > standard bg of the window I suppose, but text fields are likely to have a
> > different background, aren't they? and the same happens for the foreground,
> > no?
> >
>
> Absolutely. As it stands now, the patch is mostly just a quick hack to
> replace what WINGs historically has called "white", "black", "gray", and
> "darkGray". I chose names that represented what these colors (most of
> the time) are used for. There are definitely major issues with these
> choices. (White is a big problem. It is used for button highlights,
> selected text, and textfield backgrounds, all of which are very different.)
>
> The ultimate solution I think would be to gut the hardcoded names
> entirely and create more descriptive names. I'm beginning to work on
> this, but it will take some time. :)
A possible solution to help find the list of used colours would be to add the
attribute deprecated to the variables in the current structure, that would
point you all current usage, and then with a little bit of work you'd get a
good base for choosing names
> >> +{
> >> + WMTheme *theme;
> >> + WMUserDefaults *defaults;
> >> +
> >> + char *background;
> >> + char *foreground;
> >> + char *shadow;
> >> + char *highlight;
> >> + char *unselectedTabBackground;
> >> + char *unselectedTabHighlight;
> >> +
> >> + defaults = WMGetStandardUserDefaults();
> >> +
> >> + if (defaults) {
> >> + background = WMGetUDStringForKey(defaults, "Background");
> >> [...]
> >> +
> >> + theme->background = WMCreateNamedColor(scr,background,True);
> >> + if (!theme->background)
> >> + theme->background = WMCreateRGBColor(scr, 0xaeba, 0x,
> >> 0xaeba, True);
> > I'm not sure this behaves as good as you expect.
> >
> What do you mean?
Maybe I should not be so cryptic... There are 2 things in this code:
- if 'defaults' happens to be NULL, then 'background' will be uninitialised,
which WMCreateNamedColor may not like that much; yet a look at
WMGetStandardUserDefaults shows that it cannot be NULL so the code should be
simplified to avoid a potential compiler warning on uninitialized variable
- if the key "Background" does not exist (yet), then background will be NULL,
which is also not so great to call WMCreateNamedColor with
There are also a few more details a lot less important:
- today I have not tried hard to understand where the settings were actually
saved, but that a point I care about, because I always feel picky about keeping
data properly organised
- some colours should not have a hard-coded default but use a formula, for
example the light+dark greys used make that 3D like effect: if you specify an
orange colour for the background (wouldn't that be lovely?) you'd expect the 3D
effect to use automatically light-orange and dark-orange, it's just a matter of
choosing the proper coefficients to get the calculated colours to fall back to
the current defaults when called with
Re: [PATCH] Basic WINGs theming
On 11/05/2013 05:58 PM, Christophe wrote:
> Although I do like the idea brought by the patch, there are a few things in
> this implementation that I would suggest to do differently:
Absolutely! I'm a mathematician, not a programmer, so I appreciate all
the input I can get!
>> +WMTheme* W_GetTheme(WMScreen *scr);
> I think this should appear in the visible API of the toolkit.
> A theme is something internal to the toolkit, the application using it should
> not see it
>
I'm a little confused here. Are you suggesting that themes should be
visible or not? Also, what determines this? Is it WINGs.h vs.
WINGsP.h? I couldn't find any documentation on what goes where, so I
just tried to follow the example of what was already there.
>> +typedef struct WMTheme {
>> +WMColor *background;
>> +WMColor *foreground;
>> +WMColor *shadow;
>> +WMColor *highlight;
>> +WMColor *unselectedTabBackground;
>> +WMColor *unselectedTabHighlight;
>> +} WMTheme;
> I would suggest to rethink the names and organisation of this structure,
> because there will need more, for example: background is for what? the
> standard bg of the window I suppose, but text fields are likely to have a
> different background, aren't they? and the same happens for the foreground,
> no?
>
Absolutely. As it stands now, the patch is mostly just a quick hack to
replace what WINGs historically has called "white", "black", "gray", and
"darkGray". I chose names that represented what these colors (most of
the time) are used for. There are definitely major issues with these
choices. (White is a big problem. It is used for button highlights,
selected text, and textfield backgrounds, all of which are very different.)
The ultimate solution I think would be to gut the hardcoded names
entirely and create more descriptive names. I'm beginning to work on
this, but it will take some time. :)
>> +{
>> +WMTheme *theme;
>> +WMUserDefaults *defaults;
>> +
>> +char *background;
>> +char *foreground;
>> +char *shadow;
>> +char *highlight;
>> +char *unselectedTabBackground;
>> +char *unselectedTabHighlight;
>> +
>> +defaults = WMGetStandardUserDefaults();
>> +
>> +if (defaults) {
>> +background = WMGetUDStringForKey(defaults, "Background");
>> [...]
>> +
>> +theme->background = WMCreateNamedColor(scr,background,True);
>> +if (!theme->background)
>> +theme->background = WMCreateRGBColor(scr, 0xaeba, 0x,
>> 0xaeba, True);
> I'm not sure this behaves as good as you expect.
>
What do you mean?
Thanks again. I really appreciate it!
Doug
Re: [PATCH] Basic WINGs theming
Hi,
Although I do like the idea brought by the patch, there are a few things in
this implementation that I would suggest to do differently:
- Doug Torrance a écrit :
> [...]
>
> diff --git a/WINGs/WINGs/WINGs.h b/WINGs/WINGs/WINGs.h
> index 0104e03..ff9eaef 100644
> --- a/WINGs/WINGs/WINGs.h
> +++ b/WINGs/WINGs/WINGs.h
> @@ -349,6 +349,8 @@ typedef struct W_Pixmap WMPixmap;
> typedef struct W_FontWMFont;
> typedef struct W_Color WMColor;
>
> +typedef struct WMTheme WMTheme;
> +
For consistency, should not this be:
struct W_Theme WMTheme
> typedef struct W_Screen WMScreen;
>
> typedef struct W_View WMView;
> @@ -881,6 +883,8 @@ unsigned short WMGetColorAlpha(WMColor *color);
>
> char* WMGetColorRGBDescription(WMColor *color);
>
> +WMTheme* W_GetTheme(WMScreen *scr);
I think this should appear in the visible API of the toolkit.
A theme is something internal to the toolkit, the application using it should
not see it
> /* ---[ WINGs/widgets.c ]- */
>
> WMScreen* WMWidgetScreen(WMWidget *w);
> diff --git a/WINGs/WINGs/WINGsP.h b/WINGs/WINGs/WINGsP.h
> index de01412..df5cfc4 100644
> --- a/WINGs/WINGs/WINGsP.h
> +++ b/WINGs/WINGs/WINGsP.h
> @@ -64,6 +64,17 @@ typedef struct W_DraggingInfo {
> struct W_DragDestinationInfo* destInfo; /* infos needed by destination */
> } W_DraggingInfo;
>
> +/* ---[ wcolor.c ]- */
> +
> +typedef struct WMTheme {
> + WMColor *background;
> + WMColor *foreground;
> + WMColor *shadow;
> + WMColor *highlight;
> + WMColor *unselectedTabBackground;
> + WMColor *unselectedTabHighlight;
> +} WMTheme;
I would suggest to rethink the names and organisation of this structure,
because there will need more, for example: background is for what? the standard
bg of the window I suppose, but text fields are likely to have a different
background, aren't they? and the same happens for the foreground, no?
> [...]
> @@ -265,6 +276,8 @@ typedef struct W_Screen {
> struct W_View *modalView;
> unsigned modalLoop:1;
> unsigned ignoreNextDoubleClick:1;
> +
> +WMTheme *theme;
> } W_Screen;
I would suggest to not use a pointer here, but use the structure in place.
> [...]
> - scr->white = WMCreateRGBColor(scr, 0x, 0x, 0x,
> True);
> + scr->white = scr->theme->highlight;
> [...]
> - scr->black = WMCreateRGBColor(scr, 0, 0, 0, True);
> + scr->black = scr->theme->foreground;
I'm not sure this is the right way to do it. I would think that 'white' should
be white, and not some other color; should not it be the widget that use
scr->theme.xxx instead of explicit scr->white?
> [...]
> +WMTheme *W_GetTheme(WMScreen *scr)
Considering what the function does, I am not sure the name is right. This name
suggests me:
WMTheme *W_GetTheme(WMScreen *scr) { return scr->theme; }
Where what is does is more loading the theme and installing it (W_InstallTheme?)
> +{
> + WMTheme *theme;
> + WMUserDefaults *defaults;
> +
> + char *background;
> + char *foreground;
> + char *shadow;
> + char *highlight;
> + char *unselectedTabBackground;
> + char *unselectedTabHighlight;
> +
> + defaults = WMGetStandardUserDefaults();
> +
> + if (defaults) {
> + background = WMGetUDStringForKey(defaults, "Background");
> [...]
> +
> + theme->background = WMCreateNamedColor(scr,background,True);
> + if (!theme->background)
> + theme->background = WMCreateRGBColor(scr, 0xaeba, 0x,
> 0xaeba, True);
I'm not sure this behaves as good as you expect.
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
begin quoting "Rodolfo García Peñas (kix)" as of Tue, Nov 05, 2013 at 11:32:08PM +0100: > On 05/11/2013 21:57, Carlos R. Mafra wrote: [snip] > > It's been only a day or two since the patch and I'm still thinking and > > hoping to read more convincing arguments. It would help if the patch > > included an entry in the NEWS file to teach people about it (including > > the color syntax). Otherwise I think only a handful of people will be > > aware of it (nevermind use it). > > Some patches were accepted and the NEWS file was updated later. Arguably a bad idea, and a lapse in judgement that shouldn't be repeated. > > I don't like the patch because it smells like "let's do it simply because > > "I don't like" -> 1 person. > "I like" -> 3 people. > > Outcome: The patch is not accepted (yet, sorry) At least 2, because any accusation of a code smell requires a deeper investigation (in my book). There's also the distinction between "that's a good feature" and "that's a good way to implement the feature". [chop] > > It is just me being conservative and trying to tell people what I think > > comes close to the edge of acceptance. > > Who set the edge? Can more people change the edge? The edge is based on the aesthetic sensibilities of the curator; better arguments are the way to change the edge, not the tyranny of the majority. If you're not going to have a small team handle the duties and argue among themselves, then you've got to rely on a single curator. You can always fork the repo and run it yourself in parallel. That's the ultimate open-source solution to "I'm unhappy with the curation of $project." [snip] > > And in this particular case you mention I said the patch would be > > accepted if it was not compiled by default. > > I know what you said. But, why (only) you can say what is accepted or > not? Could you accept a patch in the git that you don't agree with? You're talking about forcing him to discard his aesthetic? Someone had better be prepared to pony up some cash and hire him, so overruling that aesthetic sense can be justified. ;-) I *like* that someone is giving pushback on patches that don't meet up with someone's sense of what's appropriate. If some reasonable patches are being rejected or deferred due to some concerns, the _proper_ solution is not to call for a vote, but to engage in reasonable discourse about the pros and cons. (If you can't come up with a con, your pros are meaningless, and can reasonably be ignored. There's always a con, and if it's not out in the open, the whole thing's a con.) [snip] > > I try to be reasonable in my decisions, but I prefer to err on the > > conservative rather than the "accept all patches" side. > > Yes, but there are more people in the mail list. Probably they can help > with the decisionmaking. Let me register a standing thumbs-down vote on any patch based on trying to make WindowMaker more like /other/ window managers. I don't use those other window managers for a *reason*. I'm very selfish... I want it to work well for me. "Looking old" is not a good engineering justification for a change. (On the other hand, I'm also not a fan of hard-coding anything. I'd rather have a configuration file somewhere, even if the values in that file are unknown and unchanging.) -- SJS -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
begin quoting Carlos R. Mafra as of Tue, Nov 05, 2013 at 06:57:53PM -0200: [snip] > I try to be reasonable in my decisions, but I prefer to err on the > conservative rather than the "accept all patches" side. A prudent gatekeeper is a good thing. Every patch submission deserves a response, but curators need a few days a week to work, and a couple of days to review the patches, and a day off now and again to go out into the Big Blue Room. You're doing fine. -- SJS -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On 05/11/2013 21:57, Carlos R. Mafra wrote: > On Tue, 5 Nov 2013 at 20:41:40 +0100, "Rodolfo García Peñas (kix)" wrote: >> Hi, >> >> You are doing a very good job with window maker. Testing patches, trying >> new things and of course, the git management. Is a hard work and you are >> always ready to do it. I only can say, thanks a lot. >> >> However, I cannot understand your logic about don't include some patches >> and the way to do it. Yesterday, some developers said that they agree >> with the patches about WINGs theming, but you didn't include the >> patches. You didn't explain why, you have your own idea about it (not >> include them) and for you the topic is closed. > > It's been only a day or two since the patch and I'm still thinking and > hoping to read more convincing arguments. It would help if the patch > included an entry in the NEWS file to teach people about it (including > the color syntax). Otherwise I think only a handful of people will be > aware of it (nevermind use it). Some patches were accepted and the NEWS file was updated later. > I don't like the patch because it smells like "let's do it simply because "I don't like" -> 1 person. "I like" -> 3 people. Outcome: The patch is not accepted (yet, sorry) > we can, because it is cool to be able to change how the widgets look after > all these years". I understand the reasons why someone thinks it is cool, > but that is not a strong argument to include features (just think > about what would happen otherwise). > > It is just me being conservative and trying to tell people what I think > comes close to the edge of acceptance. Who set the edge? Can more people change the edge? >> We have other similar cases, like for example patches about window maker >> replaces other window managers and others replace window maker [1]. >> >> I feel uncomfortable with these situations. > > This is not too fair because it is biased, only the non-accepted > patches are remembered and quoted. No, as I said, you made/make a lot of good work. I am talking about the decisionmaking. I don't like some patches were included, for example, because they don't have a right code style, but the patches were accepted. Yes, usually, you are the only person that checks the patches. > And in this particular case you mention I said the patch would be > accepted if it was not compiled by default. I know what you said. But, why (only) you can say what is accepted or not? Could you accept a patch in the git that you don't agree with? http://lists.windowmaker.org/dev/msg05335.html OTOH "DEBUG option"? IMO is not a debug option, is a feature. > I try to be reasonable in my decisions, but I prefer to err on the > conservative rather than the "accept all patches" side. Yes, but there are more people in the mail list. Probably they can help with the decisionmaking. >> I think more people could upload changes to the git, the git upload >> could be done using votes, more people review the patches,... be more >> open. I said this idea more times. But I had the same result. >> I don't want start a war. I don't want create a wmaker forks here and >> there and I cannot offer anything. But I like the democratic projects. >> >> Regards, >> kix. >> >> [1] http://lists.windowmaker.org/dev/msg05199.html -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
RE: [PATCH] Basic WINGs theming
> -Original Message- > From: Carlos R. Mafra [mailto:crma...@gmail.com] > It's been only a day or two since the patch and I'm still thinking and hoping > to > read more convincing arguments. It would help if the patch included an entry > in the NEWS file to teach people about it (including the color syntax). > Otherwise I think only a handful of people will be aware of it (nevermind use > it). I'll work on updating the patch to include a NEWS entry tonight. Ultimately, if this feature is accepted, I would like to make it configurable in WPrefs. Doug
Re: [PATCH] Basic WINGs theming
On Tue, 5 Nov 2013 at 20:41:40 +0100, "Rodolfo García Peñas (kix)" wrote: > Hi, > > You are doing a very good job with window maker. Testing patches, trying > new things and of course, the git management. Is a hard work and you are > always ready to do it. I only can say, thanks a lot. > > However, I cannot understand your logic about don't include some patches > and the way to do it. Yesterday, some developers said that they agree > with the patches about WINGs theming, but you didn't include the > patches. You didn't explain why, you have your own idea about it (not > include them) and for you the topic is closed. It's been only a day or two since the patch and I'm still thinking and hoping to read more convincing arguments. It would help if the patch included an entry in the NEWS file to teach people about it (including the color syntax). Otherwise I think only a handful of people will be aware of it (nevermind use it). I don't like the patch because it smells like "let's do it simply because we can, because it is cool to be able to change how the widgets look after all these years". I understand the reasons why someone thinks it is cool, but that is not a strong argument to include features (just think about what would happen otherwise). It is just me being conservative and trying to tell people what I think comes close to the edge of acceptance. > We have other similar cases, like for example patches about window maker > replaces other window managers and others replace window maker [1]. > > I feel uncomfortable with these situations. This is not too fair because it is biased, only the non-accepted patches are remembered and quoted. And in this particular case you mention I said the patch would be accepted if it was not compiled by default. I try to be reasonable in my decisions, but I prefer to err on the conservative rather than the "accept all patches" side. > I think more people could upload changes to the git, the git upload > could be done using votes, more people review the patches,... be more > open. > > I don't want start a war. I don't want create a wmaker forks here and > there and I cannot offer anything. But I like the democratic projects. > > Regards, > kix. > > [1] http://lists.windowmaker.org/dev/msg05199.html > -- > ||// //\\// Rodolfo "kix" Garcia > ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
Hi, You are doing a very good job with window maker. Testing patches, trying new things and of course, the git management. Is a hard work and you are always ready to do it. I only can say, thanks a lot. However, I cannot understand your logic about don't include some patches and the way to do it. Yesterday, some developers said that they agree with the patches about WINGs theming, but you didn't include the patches. You didn't explain why, you have your own idea about it (not include them) and for you the topic is closed. We have other similar cases, like for example patches about window maker replaces other window managers and others replace window maker [1]. I feel uncomfortable with these situations. I think more people could upload changes to the git, the git upload could be done using votes, more people review the patches,... be more open. I don't want start a war. I don't want create a wmaker forks here and there and I cannot offer anything. But I like the democratic projects. Regards, kix. [1] http://lists.windowmaker.org/dev/msg05199.html -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On Mon, 04 Nov 2013, Torrance, Douglas escribió: > > > From: Rodolfo García Peñas [k...@kix.es] > > Only one comment about them, probably the theme variable should be included > > in the global variable, not in scr. > > Thanks, Kix! > > Which global variable are we talking about? I know Window Maker has > w_global, but I'm not seeing one in WINGs. I may be completely wrong, but it > seems like we wouldn't be able to assume WINGs has access to Window Maker > variables, e.g., running wdm or, for whatever reason, running WPrefs in Unity > or something. My mistake. Your code is ok :-) kix > I chose to put the theme in the WMScreen since everything else seemed to be > put there (the original colors, fonts, etc.). Also, Window Maker has all its > theme information in the WScreen. > > Doug > > -- > To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
RE: [PATCH] Basic WINGs theming
> From: Rodolfo García Peñas [k...@kix.es] > Only one comment about them, probably the theme variable should be included > in the global variable, not in scr. Thanks, Kix! Which global variable are we talking about? I know Window Maker has w_global, but I'm not seeing one in WINGs. I may be completely wrong, but it seems like we wouldn't be able to assume WINGs has access to Window Maker variables, e.g., running wdm or, for whatever reason, running WPrefs in Unity or something. I chose to put the theme in the WMScreen since everything else seemed to be put there (the original colors, fonts, etc.). Also, Window Maker has all its theme information in the WScreen. Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
Let me raise my voice as the guy who made the Debian Linux spinoff "Window Maker Live" (aka wmlive) available, which uses Window Maker as default graphical interface, and who was forced to base some design decisions based only(!) on the theming shortcomings of WINGs. On 11/04/2013 06:00 PM, Carlos R. Mafra wrote: > wmaker successfully reproduces the look and feel of NeXTSTEP and most > applications don't. But that's how things are. > The way things are, at least for GTK2 based applications someone was able to create a NeXTish theme, and this allowed wmlive to have a more or less homogeneous look and (almost) feel. Luckily this also applies to some extend to some QT based applications, for which a compatibility theming layer to GTK2 exists. All things GTK3 had to be excluded in wmlive simply because there is still no way to make it adapt to this limited NeXTish looks of WINGs. The other way round would have simply been impossible, as WINGs does not offer anything providing the depth of theming capabilities other toolkits provide. In fact, in order to have wmlive look minimally consistent, everything needed to be adapted to and to revolve around WINGs. This is so 90's! > WINGs looks like it was supposed to look, so that's why it is hardcoded. > I certainly would love to have these shortcomings of WINGs to be amended, and for this i do welcome Doug's patches. Thanks Doug! Personally i don't like Window Maker because it looks and feels like NeXTSTEP or because to some degree even shares some common ground with GNUstep (which i don't care about anymore in context of real life BTW). No, i like it because of its window manager capabilities, and i would definitely prefer it to be able to also acquire some other looks. Yes, this is cosmetics, but then again it is also cosmetics limiting Window Maker and WINGs to just one outdated boring look. So if there is a possibility to get rid of this visual monotony, i am all in for it. Furthermore, in context of the usual standard desktop mess of Linux, wmaker is well advised to offer as much compatibility as possible, and this defintely also includes theming capabilities. There are a multitude of standard applications out there who have stood the test of time and simply define desktop standards which wmaker/WINGs has no choice to ignore anymore. I for one would love to see Window Maker finally enter the 21st century instead of eternally staying stuck in last century's 90's. Thanks again, Doug! -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On Mon, 04 Nov 2013, Torrance, Douglas escribió: > > I'm not sure about whether this is a good idea. The default look is classic > > and > > I'd guess few people would ever want to change how wmaker looks like. > > For the classic look, a user just has to not touch the WMGLOBAL file. It's > still the default. > > As the writer of the patch, I'm certainly one of the people who would like to > change the look. :) The window manager itself is extremely customizable. I > think it would be nice if the corresponding widgets were as well. (It's > still nowhere near as powerful. There's no gradient or pixmap support, just > solid colors.) > > Doug +1 for this patch. I think is good idea the people have the option to change things. I have a bug in the debian BTS about problems with colors, see [1]. If the user can change things, probably this wishlist bugs could be solved. Are only about 70 lines more only, moreover, the patches are clearer than the original code, for example: - tPtr->lightGray = WMCreateRGBColor(scr, 0xd9d9, 0xd9d9, 0xd9d9, False); - tPtr->tabColor = WMCreateRGBColor(scr, 0x8420, 0x8420, 0x8420, False); + tPtr->lightGray = scr->theme->unselectedTabHighlight; + tPtr->tabColor = scr->theme->unselectedTabBackground; Only one comment about them, probably the theme variable should be included in the global variable, not in scr. Thanks for your patches Doug! [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=21888 -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
The patch is quite small and only those who want (or need it) will use it.
Some people have special needs with colors: thats why most software come
with the option for high contrast colors. It would be nice to have
something similar in WM.
On Mon, Nov 4, 2013 at 11:56 AM, Carlos R. Mafra wrote:
> On Sun, 3 Nov 2013 at 23:29:33 -0600, Doug Torrance wrote:
> > WINGs widgets use a palette of six colors. (Essentially, just four.
> There are
> > two colors used only for unselected tabs in tabviews.) This patch
> allows a user
> > to declare these six colors in ~/GNUstep/Defaults/WMGLOBAL, e.g.,
> > {
> > Background = color1;
> > Foreground = color2;
> > Shadow = color3;
> > Highlight = color4;
> > UnselectedTabBackground = color5;
> > UnselectedTabHighlight = color6;
> > }
> > ---
> > WINGs/WINGs/WINGs.h | 4
> > WINGs/WINGs/WINGsP.h | 13 +++
> > WINGs/wcolor.c | 61
>
> > WINGs/widgets.c | 2 ++
> > WINGs/wtabview.c | 4 ++--
> > 5 files changed, 78 insertions(+), 6 deletions(-)
>
>
> I'm not sure about whether this is a good idea. The default look is
> classic and I'd guess few people would ever want to change how
> wmaker looks like.
>
>
> --
> 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: [PATCH] Basic WINGs theming
> -Original Message- > From: Iain Patterson [mailto:w...@iain.cx] > >That said, I struggled to come up with any colourschemes which don't look > bad because the same colours are used in too many places due to the limited > palette. If we could expand that palette I think there is real potential > here. This is certainly possible. I just took the easy way out in my patch and gave the user the possibility of redefining the colors WINGs calls "white", "black", "gray", and "darkGray" (and "lightGray" and "tabColor" for the two special unselected tab cases). The "white" color is especially problematic I think, because it is used both for highlighting selected things and as a highlight on the edges of buttons. If you want a nice bright color for highlighting text (like the orange that Ubuntu uses in its Radiance and Ambiance GTK themes), then the buttons look silly. But if you want your button highlights to be just a slightly lighter shade of your background color, you can't really make out the highlighted text. I might play around with this in the future. Doug
Re: [PATCH] Basic WINGs theming
On Mon, 4 Nov 2013 at 16:35:16 +, Iain Patterson wrote: > Quoth Carlos R. Mafra, > > >I'm not sure about whether this is a good idea. The default look is > >classic and I'd guess few people would ever want to change how > >wmaker looks like. > > The chances of making a third-party application look consistent > with wmaker is fairly slim these days, old GTK2 apps with the > GTK2-Step theme notwithstanding. If we can approach the problem the > other way and make wmaker look like the apps then I'm in favour. I don't think that this is a "problem". wmaker successfully reproduces the look and feel of NeXTSTEP and most applications don't. But that's how things are. WINGs looks like it was supposed to look, so that's why it is hardcoded. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
Quoth Carlos R. Mafra, I'm not sure about whether this is a good idea. The default look is classic and I'd guess few people would ever want to change how wmaker looks like. The chances of making a third-party application look consistent with wmaker is fairly slim these days, old GTK2 apps with the GTK2-Step theme notwithstanding. If we can approach the problem the other way and make wmaker look like the apps then I'm in favour. That said, I struggled to come up with any colourschemes which don't look bad because the same colours are used in too many places due to the limited palette. If we could expand that palette I think there is real potential here. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
RE: [PATCH] Basic WINGs theming
> I'm not sure about whether this is a good idea. The default look is classic > and > I'd guess few people would ever want to change how wmaker looks like. For the classic look, a user just has to not touch the WMGLOBAL file. It's still the default. As the writer of the patch, I'm certainly one of the people who would like to change the look. :) The window manager itself is extremely customizable. I think it would be nice if the corresponding widgets were as well. (It's still nowhere near as powerful. There's no gradient or pixmap support, just solid colors.) Doug -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On Sun, 3 Nov 2013 at 23:29:33 -0600, Doug Torrance wrote:
> WINGs widgets use a palette of six colors. (Essentially, just four. There
> are
> two colors used only for unselected tabs in tabviews.) This patch allows a
> user
> to declare these six colors in ~/GNUstep/Defaults/WMGLOBAL, e.g.,
> {
> Background = color1;
> Foreground = color2;
> Shadow = color3;
> Highlight = color4;
> UnselectedTabBackground = color5;
> UnselectedTabHighlight = color6;
> }
> ---
> WINGs/WINGs/WINGs.h | 4
> WINGs/WINGs/WINGsP.h | 13 +++
> WINGs/wcolor.c | 61
>
> WINGs/widgets.c | 2 ++
> WINGs/wtabview.c | 4 ++--
> 5 files changed, 78 insertions(+), 6 deletions(-)
I'm not sure about whether this is a good idea. The default look is
classic and I'd guess few people would ever want to change how
wmaker looks like.
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
