Re: Atom a new text-editor built by the Github people...
On Sun, 2014-03-02 at 10:41 -0500, Alex GS wrote: Sorry, disegard this message, it's a closed source and useless app, nevermind :-( well they haven't released anything yet, so we can't jump to conclusions - it might be (although unlikely) paid for + open source.. -- Marco Scannadinari m...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
[Fwd: Re: Middle click, dumbing down Slashdotted]
On Sun, 2013-09-29 at 12:34 -0700, Leslie S Satenstein wrote: So, we also look at the memory consumption in my 1 gig notebook, and see that 1/3 of it is to support icon presentation. On my box it is 1563MiB or RAM (`free --mega`), albeit with Evolution, Epiphany, and gnome-terminal open. Memory usage is the natural consequence of desktop effects and polish. How many clicks on average does it take to find a program whose name you don't recall? 4/5 if you use the mouse. If you don't know the name, just type in what kind of app or what category it is, e.g. editor-gedit(enter). A good maintainer will ship a .desktop file that contains a set of relevant tags. And when you change things because you think they are better, it is not that we are resistant to change, we are resistant to fiddling because of boredom. Is that what you think the Gnome devs are basing their decisions on? Your status as an experienced Information Technology specialist. should really tell you otherwise I suspect, and I am not sure why, but Gnome will be forked, and something better will arise. It has[0][1][3], if they are better (in your opinion), then use them. If not, then what does that say when three forks of a desktop can't get it right? How did we get on to this anyway? [0] http://mate-desktop.org/ [1] http://cinnamon.linuxmint.com/ [3] SolusOS Consort (no project or source code page) -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Middle click, dumbing down Slashdotted
On Thu, 2013-09-26 at 04:44 -0700, Leslie S Satenstein wrote: Gnome is emulating the Android interface citation needed? -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME's official GitHub mirror
On Thu, 2013-08-15 at 16:13 +0300, fr33domlover wrote: Allow me to clarify: You're free to use github mirrors, it's your right to do so. But I have the right not to cooperate with this. All Gnome maintainers have this right. If you're going to enable those github mirrors, make sure any maintainer can easily turn off mirroring for their module. why? By releasing your code under a Free license such as the GPL, you are allowing others to take your code, and essentially, do what they want with it. Free licenses by design are made to allow this, and if your app is part of the Gnome project, then Gnome are free to do what they want with it, in this case, to create a *read-only* mirror on GitHub in the intrest of convenience. -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME throbber inconsistencies?
I'd be pretty surprised if DMZ has been forked. Jakub Steiner, who designed DMZ, is one of the current gnome-themes-standard maintainers, and I'm not aware of any changes to the pointer theme. I don't know for sure that it has been forked, but it seems quite likely because of the similarities between DMZ-Black and the Adwaita cursor theme. The only (noticable) difference is the throbber. -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME throbber inconsistencies?
And with regards to how I thought that the Tango project created the throbber, I was blindly convinced by these links: commacommacrash.com/2007/08/animated-gif-for-tango-throbber.html commons.wikimedia.org/wiki/File:Spinning_wheel_throbber.gif -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME throbber inconsistencies?
Cosimo or Benjamin can tell you more about the specifics. Thanks. By Cosmio and Benjamin, do you mean Cosimo Cecchi and Benjamin Otte? -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME throbber inconsistencies?
Indeed the reason they're different is the line style the shell spinner - and former GtkSpinner widget - has is not possible to do with pure CSS gradients while keeping arbitrary scalability of the widget. Our long term plan for this would be to have a set of predefined sizes for the spinner (as we currently do for icons). This would make it possible to achieve the animation from the theme using actual image assets instead of layered CSS gradients, which gives us all the flexibility we need to ensure consistency, but no-one stepped in and actually tried to implement this idea yet. I think using the very nice throbber by the Tango people would look a lot nicer and reduce the work (?) needed to standardise the throbber sizes in GNOME. Im sure there's a lot I'm missing, but the ideal scenario (for me) is to revert to the Tango throbbers and subsequently their DMZ-* cursors as well. Not to be rude, but does anyone know why the cursors were forked from DMZ? (Apart from it needing to be black, but there is a DMZ-AA / DMZ-Black anyway...) -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME throbber inconsistencies?
Hi, The GTK+ throbber is a dotted animation, but the one used in clutter apps / UIs use a different icon - instead of dots, it uses longer lines. Is this a design decision? If it is please consider the points made below: - It is inconsistent without an obvious reason as to why this is - The clutter-themed throbber is also used in the Adwaita cursor theme (forked from DMZ-Black(?)), and with the lines which are thicker than the dotted GTK one, it makes the cursor look excessively cluttered (pun not intended), especially in the in progress cursor (I don't know what it is called, but it is the one in between the (O) loader, in Windows it is the Hourglass, and in OSX it is the spinning beach ball, and the normal cursor. It is basically the normal cursor with the circle attatched. It takes up nearly all space in its allocated circle). See the second and third cursors from the following link for case in point: http://codzoyer.deviantart.com/art/Adwaita-Cursors-for-Windows-208885897 In my opinion, I think the throbbers should be consistent on all UIs - if this is to happen, then the GTK one should be used because of the second point outlined above. Again, is this a design desicion? Thanks, - - Marco Scannadinari ma...@scannadinari.co.uk P.S. Sorry for the HTML email - it was written on a tablet at the time ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
Hi, is there any progress with this? I there a Gnome team willing to be the pioneer and try loomio, and report about the experience? I don't belong to any team so I can't take responsibility personally (but I'll help you, if you decide to give loomio a try). Unfortunately, it seems both the design-team and desktop-devel teams are quite against the whole idea of loomio or any other community voting system. Andre Klapper also posted a link [0] to a study which suggest that commitee-oriented design processes aren't a good idea. I'm (and probably not a lot of other people) are not in a position to argue or disprove such a study, so, as much as I would like to see it be implemented, I guess that's that... [0] http://nat.org/blog/2006/02/dan-winship-on-design-by-committee/ -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
Unfortunately, we don't have the benefit of two years of betas,
so if we implement and deliver this 3.10, there is a risk of an
impendance mismatch between what's expected from the designs and
theory behind them, and how the user effectively react. Which
would bring even more negative publicity to GNOME.
This is generally a problem of every fast releasing project with
little man power, so it affected many of the features in 3.8 and
before, but at least at time we had the validation of other
systems doing the same.
To me, a reasonable compromise (yet to decide if technically
possible) would be to have a feature branch, that is not
merged in master until after it's thoroughly user tested. And
that possibly gets punted to 3.12 or never, if it turns out to
be a bad idea.
I completrely agree.
Sorry to rant, but nobody outside this list (or maype
gnome-{design,desktop}) has been notifieied of this proposal that will
probably be merged. In fact, I think that these sorts of subtle
design-based decisions should be held in something like loomio (see
recent loomio post in desktop-devel), to be later implemented if the
response is positive. I think your suggestion of a feature branch can
be a worthy compromise, though.
--
Marco Scannadinari ma...@scannadinari.co.uk
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
I think you're mixing up decisions with doing a study? E.g. you assume because of such a tool suddenly 'GNOME 3' will work different? (to be clear: I'm asking, not suggesting) No, I don't think that GNOME will suddenly become the perfect DE, but certain decisions, such as the location of the close button on fullscreen apps, could be improved a lot and polls could be used as evidence for user testing or feedback, rather than saying We thought it was the right thing to do. (for example) BTW Aren't decisions made based on user studies if availible? -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
On Tue, Apr 16, 2013 at 10:06:51PM +0100, Marco Scannadinari wrote: If someone posts a proposal on gnome-devel, for example, it would not be efficient or easy for each user to give their approval: Yeah I love Here you clearly assume that it will be used for software development. I did say for example - this service can be used globally accross the GNOME Foundation and its groups. If you want to test something, a usability study should be done. Not random people who show up for some decision. That's going to be just as biased as having the decision taken by the current people. I'm not saying that we should invite everyone to the discussion, but even so, having random people would be completely un-biased, as they would probably have no affiliation with the project (for usability studies anyway). We could probably have a discussion locked to members of the design-team, devel-team(?), translation-team, etc, and have invites sent if someone is not part of the team and would be appreciated in the discussion. Even if this feature does not exist, the source is free and can be modified on GNOME's own loomio instance if the devs are not willing to implement the potential commit(s). -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
On Tue, Apr 16, 2013 at 01:49:48PM -0700, Sriram Ramkrishna wrote: On Tue, Apr 16, 2013 at 12:53 PM, Olav Vitters o...@vitters.nl wrote: On Mon, Apr 15, 2013 at 05:21:15PM +0100, Marco Scannadinari wrote: [0] (Restricted in that users do not know that it exists, or that they are allowed to participate. And if they do, they may not be notified of a decision meeting when it occurs.) I don't get this at all. This implies that there are decision meetings and that the decision is taken equally by the number of people part of the decision. I don't see how having a web based tool changes anything regarding being able to be allowed to participate. They do exist. We in the marketing team make tactical and strategic decisions all the time. It might be in code space, but other teams do use them. I think this particular tools documents what decision was made and in what context. That's a little hard to do if you have to scan through emails at least for hte marketinig team. Of course it implies that we have some discipline to do this. :-) So you want to have random people suddenly join, be of the decision and have equal say? I find that a little bit weird. Mailing lists are not designed for vote-taking, proposals, and such - the primary contents of nearly all mailing lists are discussions and announcements. If someone posts a proposal on gnome-devel, for example, it would not be efficient or easy for each user to give their approval: Yeah I love this idea please implement it, I agree., I am not in favor because $REASONS, etc, etc. There is no ticket system for taking in votes, and no standardisation in the voting and discussion procedures. It would be even harder for the poor guy who has to collect in all of the votes, which would mean discerning how much in favour the votee is of the proposal, and having to hand-file the results. With loomio, this process is automated and it is a dedicated service for these taks. At the very least, GNOME could have a test-run of it for a month or so. -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
So you want to have random people suddenly join, be of the decision and have equal say? I find that a little bit weird. As opposed to the method that we have now which is..? -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
GNOME is a free software project where all the decision making process should be transparent. Mailing lists, for example, are transparent. The tool you recommend will go against the spirit of openness and community. How? The whole service is open source, and if anything, it will increase the level of transparen[cy] in GNOME, as decisions will be opened to our end-users and the community, as opposed to them taking place in the restricted [0] form of mailing lists and IRC. [0] (Restricted in that users do not know that it exists, or that they are allowed to participate. And if they do, they may not be notified of a decision meeting when it occurs.) -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why does killing GS with SIGHUP crash on the 2nd time?
On Mon, 2013-03-04 at 22:10 -0600, meg ford wrote: Hi Marco, If you need detailed explanations you can ask on the gnome-love mailing list [1] or #gnome-love on irc.gnome.org. Thanks, I didn't know about that list -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why does killing GS with SIGHUP crash on the 2nd time?
Any concerns that killing/reloading the desktop interface isn't what an application should do in my opinion aside, the shell exposes an Eval() DBus method on org.gnome.Shell, passing global.reexec_self() will trigger a proper restart. How can I pass global.reexec_self() to org.gnome.Shell? Sorry, I have little to no (g)dbus experience. -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why does killing GS with SIGHUP crash on the 2nd time?
proxy = Gio.DBusProxy.new_for_bus_sync(
Gio.BusType.SESSION,
Gio.DBusProxyFlags.NONE,
None,
'org.gnome.Shell',
'/org/gnome/Shell',
'org.gnome.Shell',
None);
proxy.Eval('(s)', 'global.reexec_self();')
I'm really sorry - could you explain those arguments to me? - So I can
be able to reproduce them not necessarily for this program.
--
Marco Scannadinari ma...@scannadinari.co.uk
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Why does killing GS with SIGHUP crash on the 2nd time?
I'm in the process of developing an app in Python (3). One of the functions it has it the restart the shell. I would like to refrain from relying on calling commands from the shell using subprocess.call([]), and so I used: os.kill((GS PID), 1) # 1 == SIGHUP For some reason, using this command twice crashes the shell. It is not python-specific, as pkill -HUP gnome-shell and killall -HUP gnome-shell produce the same result, which is odd because Alt+F2 + r * (a lot) does not crash it. Should I be issuing a different signal to gnome-shell, or do I have to use gnome-shell --replace from the commandline? -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Most compatible AND useful toolkit for use in GNOME
Thanks everyone for your input. I've decided to go with GTK+ for now because it seems the most supported and integrate-able with GNOME. It's python binding is also quit easy to use. My next choice would be wxwidgets. Thanks, -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Most compatible AND useful toolkit for use in GNOME
Qt is an entirely unrelated toolkit, it has nothing to do with Gtk. Yes, that is true. It's not necessarily GTK I intend to use, although that is what I would *like*. Taking into consideration which is the easiest to learn, and which will be able to target the most users, Qt seems like a good toolkit for these purposes. Qt also looks quite native on the new GNOME 3.6, albeit appearing like the old GTK+ theme. I am actually quite biased towards GTK, but the idea of being able to develop for multiple platforms seems quite attractive (in regard to Qt). -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Most compatible AND useful toolkit for use in GNOME
Hi, What are your recommendations for a toolkit that is best suited to GNOME app development (obviously GTK+3), but also useful in developing apps for other distros / OSs - I feel that the general suggestion is Qt. Others have said even wxWidgets, because it draws native widgets according to the environment. Keep in mind my language of choice is python (3) and am quite new to graphical app development. Thanks, -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
