On Fri, 9 Mar 2018 11:28:01 -0500 "William L. Thomson Jr." <wlt...@obsidian-studios.com> said:
> On Fri, 9 Mar 2018 13:38:36 +0900 > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > a volunteer is not going to do something they dislike. certainly not > > readily. users have to convince the volunteer to do it. not the other > > way around (that volunteers need to be slaves to users and do work > > for them even if the volunteer disagrees and dislikes it). volunteers > > don't get paid... they do things because they desire and want to. > > it's the user's job to convince them... or for the user to stand up > > and do it themselves. :) > > Yes and no. Being a volunteer does not mean you just show up and do > what ever you want to do. I do not think anyone who thinks along those > lines has ever volunteered in person. In my area we do things like > beach cleanup, hurricane and disaster recovery. You do no get to just > show up and do what ever. You do get assigned things to do as a > volunteer. that's not how open source works. there is nothing keeping you around unlike thew moral obligation you put on yourself to volunteer to clean up after a disaster for example. they are very very very different things. also physically volunteering means that walking away is something everyone sees you do. there is a face to it. walking away from an oss project is simply stopping work. invariably there are not even real names let alone faces associated. there e never many repercussions that you'd get from the example above like your neighbours and community giving you a hard time after walking off. also cleanup after a disaster is doing what has to be done, not what someone WANTS to be done. how would you like it if you volunteered to clean up and the home owner comes by to the house you're cleaning stuff out of and says "oh by the way. paint the walls lime green... no not that green. this green. and can you rebuild my garage to be a double instead of single, also use concrete instead of gravel on the driveway..." any volunteer and organization will tell them to jump in the lake. they get the cleanup they get. not just the exact way they want it to be. the volunteers and organization decide what needs doing. not the "users". they don't get a say. > When it comes to FOSS this gets lost. People think its my time, my > volunteering, I am going to do what ever I want with my time. That is > true within reason. But that also says they only care about themselves, > not the project, or what ever they are volunteering for. that is absolutely correct. that's what it is. it's not a humanitarian effort to clean up after a disaster. it's utterly superfluous really to the daily trials and tribulations of life. it's a luxury to get your software for free. it is absolutely the job of users to convince the devs to do what they want. not to expect devs to line up and take orders. > Which if they do not care about users, that also shows they do not > care about the entity, organization, or project over all. If users must > always convince others, that will not work, and tends to not work for > projects who go down that path. that is how almost every project works. do you think you can go to a kernel dev and tell them "i want you do add feature x for me" and they will just go do it? i can name almost every tingle oss project that if a user just tells a developer "i want x" and if the dev doesn't like x .. it's not going to happen. even if user does x and submits a patch .. it doesn't mean the patch is accepted. if you believe projects are there to serve their users and just do whatever they say.. then that is a very wrong idea. it may apply to projects whose only goal in life is popularity. that's very few of them and i can tell you that it almost always ends in tears as the project falls apart technically. > Just as devs/volunteers must be motivated to fulfill a users wishes and and that is where i think you have it wrong. devs absolutely have no requirement to fulfill users wishes. none. no requirement. if they do so it's them being kind, or perhaps being inspired or motivated by an idea or a user. unless their goal is pure popularity by saying yes to anything no matter what it is or what the cost to them just for a bit of popularity. > desires. A user has to be motivated to step up. They have to want to, > and that can start with wanting to work with given developers. If they > see those developers/volunteers are just self serving. They likely will > not want to work with them. I see that to often. People with skill, but > others avoid them and the distro. Then they use that to drive off > others saying others are having that effect. Not realizing its them... > Thus despite running others off, project still suffers. what you are describing is developer utterly ignoring users. i never said that. i did say that listening is good. it does not mean they just do whatever a user asks. it goes like this: developer has the skills to do x user wants x done but can't or won't do it user wants developer to donate N hours of their life so they can have x it's the users job to convince the developer to give up those N hours time is the one resources you CANNOT buy as much of as you like even if you have the resources. there are only 24hrs in a day. and everyone's life time is limited. no one who has grown any wisdom is going to waste hours of their limited lives on something they are not convinced is worth it. it's the job of the user who wants x to convince them that sacrifice is worth it. very simple. > I am also very much for PAID volunteers. Maybe not full time or part > time, but some bounty to help with motivation on things they want no > part of or not interested in doing otherwise. aaah now PAID means it's a transaction. "in return for X money you will do what i tel you to do". if that is "fix THIS bug for $X" or "add this feature for $Y". it's a deal. an agreed on IN　ADVANCE deal. just being a developer who works sometimes on project X does not mean it's a deal that "since i donate some of my time to project X i must do whatever users tell me to". that is absolutely not the contract. a contract is where both parties give up something. A gives up money in return from specific work from B. what you want is "developers give up X time in return for Y happiness of users". that is not a given assumption. it's a contract that is user wants something has to present as a deal. if someone offer me $100,000 to sift through sewerage all day, every d for a year.. I'll tell them to go away. I don't like the deal. if they offer $500,000 I will still say the same. If you say "this feature will make me happy" ... if the feature makes ME unhappy.. i'll tell you to go away. it's not worth it. you have to CONVINCE me it is. either convince me of the sheer happiness it will create *AND* that that happiness is something i might value, or you have to find some other way... maybe it will support future features i might value, or reduce bugs which is somethong i might value etc. etc... you have to sell it. like any deal. > > e doesn't follow the "unix philosophy". quoting it doesn't work. i > > believe in efficiency. if it's something that can be controlled by > > the same group and thus can get attention and get fixed along with it > > and it needs to be integrated (desktop icons require this as does > > efficiency) then it should be part of the same process most likely. > > Maybe it should, E runs mostly on *nix. Most of the world is *nix based > now, short of Microsoft. You also end up making someones focus to wide > vs narrow. Splitting ones time also as a result. As things grow it > becomes to much for any one. simply: no. you may believe differently. i do not think it should. that comes at a cost i do not like in the slightest. the source is divided cleanly in the tree by files and directories. even into modules. but i disagree and you're going to push against decades of disagreement there. i fully well know the unix philosophy. i do not like the costs when it comes to something like enlightenment. if that is the philosophy for you ... there are other desktop projects that follow it. > I think its better for development, as things can evolve on their own > and not be bound to constraints from other things. > > > e has never been a "unix philosophy thing" for as long as it has > > existed. this is not a new thing. it's been the "have 1 process do as > > much of your day to day desktop as can be done/is sensible" and fm is > > sensible. it's not fundamentally that the shelf or e's menus or > > wallpaper handling etc. - if you want the unix philosophy then all of > > those move out to processes too. if you like that then kde is > > probably good for you. :) gnome used to be until gnome 3... :) > > What E is today ans has been does not mean it has to be that way > tomorrow. Even Apple realized their old OS and ways were garbage, and > tossed them for older stuff. Look at the result.... if you want me involved... it will stay the way it is. it is that philosophy that leads to things like: <benrob0329> I got tiers of it when i3 messed up my Subnautica (that I got working in wine pretty decently) <benrob0329> *tired <benrob0329> It takes less ram and composites, is more flexible and is closer to a full DE <raster> e takes less ram? <raster> than i3? <benrob0329> i3 with Compton anyways <raster> really? <benrob0329> My old setup was always over 400 megs <raster> you've got to be joking... <benrob0329> E is like 255 with rage and terminology open <raster> that's... bizarre <raster> i'm shocked. I never expected E to out-do i3+compton. but it does. over my dead body do we change direction to nix that advantage. > And what has happened since gnome? Less GTK3 dev, and more GTK2 dev and > desktops. Gnome did not help itself nor GTK. It just helped XFCE, Mint, > and others. That should be a learning lesson there. > > > > I just do not like any one thing taking out other stuff. The more > > > things can be limited and only effect themselves, the better IMHO. > > > > that is why e has crash recovery... :) but everything being separate > > comes with a cost. it's not cheap to have lots of processes. > > especially for things you run all the time, like a filemanager (for > > the normal icons on desktop). > > You would not need the crash recovery as such. In the past window > managers would crash and other stuff keep chugging along. Also that is > IF you can restart E in time. That is not always the case. NOT if you are also a compositor. and absolutely not in a wayland world. so crash recovery is not even an option. it's a necessary. > The thing is I do need the filemanager running all the time. Icons on > the desktop could be rendered otherwise. Like what Plasma has done as an > example. That is not related to the file manager. Having the file > manager running always just for desktop icons seems like a bit much. i'm not going to go any more into this. i know other ways of doing it. they come at complexity and/or memory and other overhead costs. i am well aware of the trade-offs. this is the one i chose for e because i am absolutely certain it's the best/right one. > > like arrows pointing in over a directory indicating you are going to > > drop the file into the directory? > > I guess not sure. There are for arrows, one in each corner, and they > like point in as part of their animation. Horrible description sorry! > > I cannot easily replicate that animation. If I drag a file over a > folder nothing happens. Just noticed I cannot drag a file into a folder > or anything. I am not sure how to trigger that animation, but seems > like its some drag and drop. Though I think its happened on regular > files not just folders. you drag over the folder. the icon becomes hilighted with arrows pointing in with animation to indicate "dropping INTO this directory". it doesn't happen to regular files because you cant drop INTO a regular file. i'm staring at ti doing this right now... it is how it's pretty much always worked for many years > > if it's that - how does it get stuck. it's objects in the canvas in > > the window.. they are drawn in the window.. so they can't remain if > > the window goes. there is no canvas to draw them anymore... > > You would think so, next time it happens I will take a screenshot and > you will see the animation remains. Its odd and annoying. what you describe is just absolutely not possible if its the "drop into this folder" stuff as above. either the description is bad or you mis-remember. but it's like saying "my pc crashed" ... but the power to it was off. it can't crash if it's off. these drop into folder icons cant appear if the canvas they are in has been deleted. they might leak memory .. that is possible, but they cant be rendered without the canvas they live in. > >so this doesn't make sense. unless its the desktop files - that > >window is the whole fulls screen canvas of the compositor... and i > >can't make the arrows stay around at all... if drop is done they go > >away. if dnd moves somewhere else they go away. > > I never full screen most anything that is rare. This tends to happen no. it has nothing to do with fullscreening windows. there is a single canvas covering ALL screens. the entire swet of visible pixels you can see across all possible screens is a big single canvas. desktop icons live in that canvas as do e menus, the shelf ... and "image bitmaps" that are windows. the windows are just "image bitmap objects" in the compositor canvas. the bug "covers all screens" canvas has no clue as to the CONTENT. it's just a blob of pixels. the pixels are rendered to a window/pixmap in x or a buffer in wayland by whatever owns that window/surface. efm windows are normal windows but the same e compositor process also owns the rendering and content of these windows too. thus it generated this pixel content for itself. > for me on accident. I accidentally click on something or drag something > and boom, stuck animation. Likely why I cannot replicate. I just know I > have seen it more than most other EFM issues. > > > it's about the only annoyance i find as its just a fast way of nuking > > a file rather than right-click .. navigate to delete, then say > > "yes"in the dialog or hit del key and say "yes" in dialog. drag and > > drop into a trashcan is faster and simpler and... it's undoable (if > > done right). > > The drag into a trashcan/recycle bin to delete is faster. Though I > cannot drag and drop into folders now... I thought you were more > wanting the extra step of not actually deleting something, but moving > it to a intermediary location in case you did not want to delete. just wanted less steps. > I always took trashcan on windows is oops I deleted that, let me get it > back from the trashcan. I kind of like that as a fail safe. Though on > KDE seems I had to go clean out those trash folders at times. Then does > nothing for you at cli, so.... the "get it back" is also a nice extra feature but simply having a quick action that is hard to "do by accident" (hitting the del key is easy to do by accident, thus the need for a dialog - also since the delete is not undoable it should be there. if we had a trashcan where deletes went instead i'd remove the dialog as deletes are undoable then, but a dnd into a traschan in the corner of your screen is nice and fast anyway) > > > Along the same lines, I cannot select multiple files/folders/icons > > > on the desktop. Though maybe related to main menu being left click. > > > You > > > > of course you can. shift and ctrl + click. you cant "rubber-band" > > select and that's because this conflicts with the main menu which > > activates on mouse down and uses the same click+drag+release style of > > use (as well as click+release then another click+release). > > Yes the "rubber-band" I missed, but figured it was due to main menu. I > use the other method, shift + ctrl, selecting the files. Just takes a > bit more time. I do not do it that often so some what moot. that was why i never wanted to remove the menu on mouse down to make rubber banding work. it just wasn't worth it unless you cover your desktop in files and it's a mess and they need rubber-band selecting... but then my take is... why did you make a mess like that to begin with? my desktop is mostly for a few file/dir shortcuts in the corners and maybe some temporary stuff now and again... and i think a normal workflow would be similar thus sacrificing the menu quickness for this i dont think is worth it. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
