[no subject]
Iain Patterson said: > > Quoth Josip Deanovic, > >> Could this behavior be made configurable through an additional option? >> In Windowmaker 0.80.2 and older versions such behavior didn't exist >> at all and for those who doesn't use that feature it might occasionally >> represent irritation (based on the keyboard shortcuts they use). > >It sounds like a bug rather than an intentional change since it > doesn't make a whole lot of sense for the arrow keys to change windows > one at a time - you could use alt-tab for that - and they used to work > intuitively. > >Easily fixed. > I can see that the issue Yury reported now got fixed and Windowmaker from the #next branch is now working as Yury described. Is there a chance to introduce an option that would make possible to turn off that feature thus making it more similar to older Windowmaker behavior? I mean, if you are doing ALT+TAB (cycling windows) and without releasing the TAB key start using LEFT/RIGHT keys, it would continue cycling windows instead workspaces as it would in 0.80.x versions. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: action of alt-tab + left/right arrow crippled
Iain Patterson said: > > Quoth Josip Deanovic, > >> Could this behavior be made configurable through an additional option? >> In Windowmaker 0.80.2 and older versions such behavior didn't exist >> at all and for those who doesn't use that feature it might occasionally >> represent irritation (based on the keyboard shortcuts they use). > >It sounds like a bug rather than an intentional change since it > doesn't make a whole lot of sense for the arrow keys to change windows > one at a time - you could use alt-tab for that - and they used to work > intuitively. > >Easily fixed. > I can see that the issue Yury reported now got fixed and Windowmaker from the #next branch is now working as Yury described. Is there a chance to introduce an option that would make possible to turn off that feature thus making it more similar to older Windowmaker behavior? I mean, if you are doing ALT+TAB (cycling windows) and without releasing the TAB key start using LEFT/RIGHT keys, it would continue cycling windows instead workspaces as it would in 0.80.x versions. P.S. Please ignore my previous e-mail without the subject set. -- Josip Deanovic -- 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 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
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.
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: 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.
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: [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 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.
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 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
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. >
