Re: systemd: Is it wrong? -> wrong order
2011/7/11 Reindl Harald > my main critic on systemd shipped als default with F15 is that > widely used services like NFS are not converted to systemd > BEFORE systemd replaced upstart > Given that Fedora only used upstart with existing SysV scripts, upstart should not have been included in the first place according to that argument. Yet you want to stick with an init system which does not have a single native service, because some services are used through systemd's SysV compatibility? Sorry, but that's hardly a credible position, it just makes you look biased against systemd. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
2011/7/11 Steve Dickson
> > Hmm? Shell only understands strings, too. What precisely are you asking
> for?
> in /etc/sysconfig/nfsservices
> set LOCKD_TCPPORT=234
>
> In nfsservice.service
>
> EnvironmentFile=-/etc/sysconfig/nfsservices
> ExecStartPre=/sbin/sysctl -w $LOCKD_TCPPORT
>
> to work.
>
That is supposed to work. However, if /etc/sysconfig/nfsservices reads:
#set LOCKD_TCPPORT=234
the variable evaluates to the empty string, not 0, so the sysctl invocation
fails. I don't think unit files support advanced bash syntax like
${LOCKD_TCPPORT:-0} ...
Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 heads up: gnome-shell for everyone!
On dom, 2011-11-06 at 22:42 +, Bojan Smojver wrote: > The existence of all those extensions that bring back sanity (apps menu in > normal view, workspaces in normal view, persistent dash for switching tasks in > normal view etc.) is the proof of the ultimate irony - the (supposedly) > biggest > innovation of gnome-shell (the overview mode) is unfortunately a mistake. Does that mean that the existence of terminal emulators for X11 is proof of graphical user interfaces being a mistake? Really, all those extensions proof is that *some* people prefer (parts of) the old interface, and cared enough to implement it as extensions. Good for them! But implying that users who don't use any of those extensions are either insane or don't exist is a stretch at best, if not plain rude. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A software center for Fedora
While I agree that our app-install story sucks, I'm far less convinced that we need yet-another-downstream solution. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On dom, 2012-01-29 at 22:57 +, Noah Hall wrote: > I'd love for Fedora become rolling simply because messing around > with preupgrade and reinstalling is oh so tedious and a waste of my > time. Why do you think more people are using Ubuntu for development? Whatever their reasons might be, Ubuntu being a rolling release distro is not one of them. Simply because Ubuntu does not do rolling releases ;-) Regards, Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On mié, 2012-02-01 at 12:01 +, Bastien Nocera wrote: > GNOME never gave an opinion on the spec, we gave an opinion on the > library, which was really just a huge pile of bugs (I know, they patched > a bunch of the applications I maintain, and I get to receive a large > number of crashers because of it). I can not comment on the quality of the library, but GNOME did comment on the spec[0] (or rather: several gnomers did) - there were a couple of objections, none of which have been addressed in the spec as far as I can tell. Florian [0] http://lists.freedesktop.org/archives/xdg/2010-January/011228.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On mié, 2012-02-01 at 18:25 +0100, Kevin Kofler wrote: > The objections weren't addressed because they objected to the very point of > the spec, making it impossible to address them without defeating the purpose > of the spec. > > One main design goal of the spec was that it should NOT be the app's job to > decide how exactly the icon will look, but the shell's. I don't think anyone made an argument for letting apps "decide how exactly the icon will look" (which is basically what XEmbed does, and everyone agrees that it's crap), but rather to avoid the other extreme of giving the shell complete power of what to display (and even whether to display anything at all). As is, applications can only hope that the shell will use enough of the data it provides to convey the information as intended, but there are no guarantees or ways to query the shell's capabilities. But I don't want to reopen that xdg discussion; I just wanted to clarify that GNOME did not ignore the spec, but refused to adopt it because it was deemed insufficient. We'll have to agree to disagree on whether the reasons brought forward justify the non-adoption. I have no problem with your opinion that the NotifierIcon spec is a good spec, but I do take issue on blaming GNOME for not adopting a spec we consider "bad" - after all, "enforcing" adoption of technology is not what freedesktop.org is supposed to be about[0] ;-) > And it makes sense: > Look at how gnome-shell deprecated the system tray entirely because it > looked totally out of place there, and is forcing everyone who wants an icon > in the panel to implement a GNOME-specific shell extension in JavaScript. You are right about requiring a Javascript extension to add items to the top panel, but you are wrong about the reasoning - it is not because the "system tray looked out of place" (which it does, but it is nevertheless still supported in the message tray), but rather because the top panel is considered "system space", which means that we do not *want* random applications to add anything to it. So even if we had adopted NotifierIcons for the top bar (which was considered), it would still have been reserved for a small set of processes (mostly gnome-settings-daemon). Given that design restriction, it becomes very much irrelevant whether the implementation uses cross-desktop technology or not. > Cross-desktop status notifiers and native Plasma widgets > (plasmoids) can sit right next to each other in the Plasma system tray and > look and feel the same, why can't gnome-shell offer the same integrated > experience rather than deprecating everything other than gnome-shell-only > extensions? Because the "integrated experience" means that there is a fixed set of system items with a defined order. Extensions can be used to "hack" the intended experience (which includes adding "non-official" icons in the top bar), but it's nothing we want normal applications to do. Applications are encouraged to interact with the message tray (== the autohiding bottom panel) via freedesktop notifications (yay, cross-desktop! ;-) Florian [0] http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On mié, 2012-02-01 at 22:18 +0100, Kevin Kofler wrote: > So the argument that you're refusing to implement a cross-desktop protocol > in order to ban random applications from adding themselves to the panel is > bogus. No, the argument for refusing to implement the protocol is that the spec is bad. I was merely pointing out that *if* we used the protocol in the top bar, it would have been as an implementation detail with no benefit to applications (e.g. no way for applications to provide options to override that behavior as you imply) > > Because the "integrated experience" means that there is a fixed set of > > system items with a defined order. > > Including a bluetooth icon on a machine which does not even have bluetooth > hardware? This is just beyond silly! *sigh* You are trolling. > Notification messages and status notifier icons are totally independent > concepts with totally different use cases and totally different practical > uses. They are separate protocols for a reason. > > Notifications (also called "passive popups") are for one-off messages you > want to show to the user to inform them of something transient. Status > notifiers are for status icons the user wants to permanently keep an eye on, > such as network connectivity (which in fact you do realize needs a status > icon, or you wouldn't have hardcoded it in your shell). Except that applications can set a 'resident' hint on notifications, in which case a representive icon is kept in the message tray, from which the notification can be recalled; together with the ability to provide actions on notifications, the experience is not different from status icons. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On mié, 2012-02-01 at 23:00 +0100, Kevin Kofler wrote: > Are you going to require a spec on drawing circles to specify that the > circumference of the circle must be between 355/113-2^-21 and 355/113 > times its diameter? No, but it would require that "circle" is drawn as circle and not a square (or just discarded without notice). The NotifyIcon spec explicitly allows either absurdity. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On jue, 2012-02-02 at 05:26 +0100, Kevin Kofler wrote: > Matthew Garrett wrote: > > Because it is the job of people who are proposing a spec to answer the > > objections of the people who perform critical analysis of the spec > > They did answer. You just didn't like their answer. Their answer was basically "this is by design, there's no way this is gonna change". To which "then it is a bad fit for us and we won't implement it" is a perfectly fine reaction. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On mié, 2012-02-01 at 17:00 -0700, Adam Williamson wrote: > Yay cross-desktop maybe, but still a freaking disaster from a UI point > of view, and the only thing I really dislike about GNOME 3 I don't think it's that bad, but that might just be me having different use patterns (for instance a common complain is that the message tray interferes with the active area of maximized terminals/xchat windows - I hardly ever maximize those windows, and didn't do so either in GNOME 2). I'm sure that a solution which addresses your issues without compromising on the design goals will be adopted in a heartbeat - feel free to get in contact with the gnome designers to provide constructive feedback (and no, you don't have to be "creative" to do that - that's their job after all ;-) Of course the implementation detail of which DBus protocol applications use to interact with the tray (Notify or NotifierIcon) is completely irrelevant for those UI problems - if it sucks for you now, implementing status notifiers in the message tray would suck just as badly. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On jue, 2012-02-02 at 01:28 +0100, Kevin Kofler wrote: > Florian Müllner wrote: > > No, but it would require that "circle" is drawn as circle and not a > > square (or just discarded without notice). The NotifyIcon spec > > explicitly allows either absurdity. > > If your icon theme thinks a square is a good way to represent the concept of > a "circle", I was talking about a supposed property called "circle", not a property "themedIcon" with a value of "circle". The spec actually contains language like this (quoting from memory, as the link to the draft on freedesktop.org is dead): "Tooltip: a descriptive string which the implementation will display as a tooltip, or any other way it seems fit, or not at all" Hint: if you don't want applications to assume a certain representation, you don't use element names which imply a representation. So rather than the example above, you should have used language like: "Description: a string providing optional details about the item; implementations are free to not use the information, so applications MUST NOT rely on it" But if you provide an element "OverlayIcon", it'd be better rendered as overlayed icon and not as dancing penguins. Regards, Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On jue, 2012-02-02 at 00:44 +0100, Kevin Kofler wrote: > >> So the argument that you're refusing to implement a cross-desktop > >> protocol in order to ban random applications from adding themselves to > >> the panel is bogus. > > > > Nobody said that. > > Florian Müllner did: Not really. We didn't implement it because: - the spec is bad - it is a bad fit for the experience we want > | You are right about requiring a Javascript extension to add items to the > | top panel, but you are wrong about the reasoning - it is not because the > | "system tray looked out of place" (which it does, but it is nevertheless > | still supported in the message tray), but rather because the top panel > | is considered "system space", which means that we do not want random > | applications to add anything to it. Or in other words: there is no "system tray" in the top bar. There are exactly two places applications can hook into: the application menu and the message tray. Extensions may be used to "hack" the designed user experience, which includes adding stuff to the top bar. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On jue, 2012-02-02 at 01:16 +0100, Kevin Kofler wrote: > Then your implementation in gnome-shell would just be half-assed and crappy, > just like your implementation of the XEmbed-based spec is. Unlike the > XEmbed-based spec, the status notifier spec actually allows apps to specify > whether their icon is "active" or not, and a good implementation will show > it in the panel if it is active and hide it behind a popup if it is not. I actually agree to that - if we used the notifier spec in the top bar, we would either compromise on the intended experience, or provide a crappy implementation. Or in other words: the spec is a poor fit for what we try to achieve, so it makes sense to not use it. > Except that this feature only works that way in GNOME and nowhere else. It > also makes some strong assumptions on how the message tray looks, which is > exactly what the status notifier spec tries hard to avoid. I disagree that it implies how the message tray looks, but it does make strong assumption on its behavior - plus it allows applications to test for every optional capability to adjust its behavior to the environment it's run in. Apparently you think this is a bad thing - fine, don't implement it. But then don't bully us into implementing a spec which *we* consider bad because it avoids any such guarantees (not by mistake, but by design as you will agree) Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On jue, 2012-02-02 at 20:11 +0100, Kevin Kofler wrote: > Florian Müllner wrote: > > I actually agree to that - if we used the notifier spec in the top bar, > > we would either compromise on the intended experience, or provide a > > crappy implementation. Or in other words: the spec is a poor fit for > > what we try to achieve, so it makes sense to not use it. > > How is the current experience any better? [...] XEmbed is just a horrible > way to implement this feature. It is not implemented with XEmbed. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On jue, 2012-02-02 at 20:17 +0100, Kevin Kofler wrote: > And the thing is, renaming "Tooltip" to "Description" will break all the > existing implementations and provide no benefit whatsoever to the end user. > It's just an internal identifier the user will never see. For all I care it > could be called "Charlie" or "Linus", as long as the spec says what it > means. "It may be this, or that, or nothing at all" is an odd definition of "saying what it means". Especially if the name already has a particular meaning (which the spec has to *undefine* to allow "alternative visualizations"). Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, Feb 2, 2012 at 9:59 PM, Kevin Kofler wrote: > Florian Müllner wrote: > > It is not implemented with XEmbed. > > If the user runs non-GNOME software which tries to bring up a system tray > icon, it is. The discussion was about GNOME shell's top bar. No application (GNOME, KDE, Unity or whatever) can add anything there (using XEmbed, NotifierIcon, libnotify or whatever). Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does gnome have two sound volume settings?
On Sun, Sep 27, 2015 at 12:52 PM, kendell clark wrote: > There seems to be two different sound volumes. I'll demonstrate. > First, go into the sound settings panel in the control center. [...] > I hear: output volume: slider 31454 31 percent. If I check the same > thing on the top bar under settings, I hear: volume slider 0.5 47 percent. Both sliders control the same volume, however the one in gnome-shell has a range from 0 to 100%, while the one in Settings allows to amplify the volume to higher values (about 150%). As it happends, 31% on a 0-150 range indeed matches 47% on a 0-100 range. To indicate that difference, the slider in Settings has a visible marker at 100%, but that obviously does not translate to screen readers - IMHO the best option would be to modify the slider in Settings to read out percentage values in the 0-150% range, however I'm not sure whether that's actually possible with ATK. Another option would be to modify the slider in gnome-shell to use the actual volume values instead of mapping them to values between 0.0 and 1.0 - the percentages would still differ due to the different upper limits, but at least the values would match up in that case. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gnome-sudoku in F21
On Sat, Sep 13, 2014 at 3:40 PM, Joachim Backes wrote: > In gnome-sudoku (gnome-sudoku-3.13.90-3.fc21.x86_64) for F21 I'm missing > the feature allowing to print multiple unsolved sudokus. You should use a user list/forum for these kinds of questions, as it is not related to developing Fedora in any way. That said, the functionality you are looking for moved to the application menu (next to the "Activities" button). -- Florian PS: They say a picture is worth a thousand words - screenshot attached ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Install Fedora Button for LiveCD
On Fri, Apr 20, 2012 at 12:00 AM, Chris Murphy wrote: > In effect it may necessitate a reboot to get that notification back, in > order to know how to install? > Not if the notification is resident, in which case it will remain in the message tray even after it has been acknowledged by the user. Regards, Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
Hey,
On Fri, Apr 20, 2012 at 9:49 AM, Kamil Paral wrote:
> I tried that out. For some reason the notification doesn't pop up after I
> run the program, is that intended?
No, it should be shown in "banner mode" like in
http://imgur.com/Gk1Az(that's a screenshot of running the unmodified
program here).
Currently that is obscure the same way the current dash launcher is. We
> would need at least to pop up that notification right after logging in, and
> then hide the notification if users clicks on it (outside the Install
> button). Ideally it should be clear that the button is still available to
> the user even if I dismiss the notification (I'm not sure how to do that).
After the notification pops down (either due to a timeout or because the
users dismisses it explicitly) the message tray ("translucent black bar at
the bottom holding notification icons") is shown for a moment to indicate
that that's where the notification went.
Another question is what happens if user doesn't dismiss it, what about
> other notifications, do they just queue and don't show up?
>
Only for the duration the notification is actively shown (as in my
screenshot), which is about two seconds if I recall correctly.
Regards,
Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On Apr 20, 2012 11:55 AM, "Jiri Eischmann" wrote: > The notification is nice, but the only job it does is that it says the > live system is installable. It really doesn't help the user find out how > to install it. The notification contains a button which is labeled "Install". I don't think users will have that much trouble figuring out what it does ... Regards, Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On Apr 27, 2012 11:34 PM, "Jared K. Smith" wrote: > Sorry Bill -- I'm confused here. Was a notification method actually > implemented? Was it enabled in F17.TC1? If so, I didn't see it. Or > was it implemented only for rawhide? It was implemented only in the sense that code was written and posted to this list for discussion. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP][RAWHIDE]: Gnome broken in Rawhide
Should be fixed by http://koji.fedoraproject.org/koji/buildinfo?buildID=701581 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Why is not enabled TapButton of touchpad on Fedora by default?
On Tue, Sep 18, 2012 at 11:41 AM, Camilo Mesias wrote: > I always enable the feature but it is an ongoing annoyance that it is > disabled at GDM, is there any way to force it to default to on for the > whole system? I have the following in /etc/dconf/db/gdm.d/10-local-settings: [org/gnome/settings-daemon/plugins/mouse] active=true [org/gnome/settings-daemon/peripherals/touchpad] tap-to-click=true You will need to run "dconf update" as root for the change to take effect. Regards, Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why is not enabled TapButton of touchpad on Fedora by default?
On Sep 18, 2012 2:56 PM, wrote: > Any ideas on the equivalent for KDM? No, sorry. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: AppData files in all application packages?
On Mon, Sep 9, 2013 at 5:36 PM, Remi Collet wrote: > Le 06/09/2013 11:33, Richard Hughes a écrit : >> [1] http://people.freedesktop.org/~hughsient/appdata/ > > I don't see any localization information in those specifications... From the above link: "Questions: [...] How do I translate this data?" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: clock-applet memory leak
On Mon, Apr 22, 2013 at 6:55 PM, Przemek Klosowski wrote: > Since clock-applet is a default install on every Fedora, I thought this > would be widely reported While it is installed on every (default desktop spin) Fedora system, it is only used by the (non-default) GNOME fallback mode, which is likely why it hasn't been reported as much as you assumed. It is also unmaintained upstream and will no longer be included in Fedora 19. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Mon, May 6, 2013 at 3:21 PM, Przemek Klosowski wrote: > Another example of such important change that recently appeared without > recourse and much discussion is the lock screen: previously, the password > unlock widget had focus so one could start typing the password, while the > new behavior is that the focus is in the clock, and one needs to hit Esc or > Enter. This is vastly off-topic of course, but this was actually a temporary limitation in GNOME 3.6 - since 3.8 (e.g. Fedora 19), you can just type in your password again. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Gnome Desktop Touchscreen Usability
On Thu, Jul 4, 2013 at 12:04 PM, Thomas Sailer wrote: > What is happening here? How can I get the shell to accept finger input too? It is fallout from the port to XInput2, see https://bugzilla.gnome.org/show_bug.cgi?id=697192. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-shell crash with Nvidia drivers (fix available but not in Fedora 24 it seems)
On Tue, 28 Jun 2016, 16:50 Michael Catanzaro, wrote: > > Hey Florian, it looks like a good time for another 3.20 release; > Yeah, I had planned another 3.20 release for a while. 3.20.3 is now pending for testing: https://bodhi.fedoraproject.org/updates/FEDORA-2016-fb66c6e22c > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: cogl soname bump
On Fri, Jan 25, 2013 at 2:42 PM, Peter Robinson wrote: > I'll work to rebuild associated deps now I just saw mutter and gnome-shell going by, thanks for taking care of that! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F22 System Wide Change: GNOME 3.16
On Thu, Jan 22, 2015 at 6:05 PM, Reindl Harald wrote: > Am 22.01.2015 um 17:59 schrieb drago01: >> This is just a game > > keep your insults for yourself > maybe for you it is just a game That was not an insult, but was referring to the software in question, gnome-2048 - which is indeed a game ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME glitches in F21 - Should they be reported and against which components?
On Mon, Jan 26, 2015 at 1:51 PM, Alexander Ploumistos wrote: > A few days ago I upgraded my main workstation to F21 and I've noticed a few > annoying glitches, but I don't know if they are all worth reporting Yes. Glitches may be minor bugs, but bugs nonetheless. > 1. Window size and position: > While some applications start with their last window size and placement, > others do not; among them, most notable is firefox. Saving and restoring window state is up to applications, so this would be a feature request for applications that don't do this already. > It usually starts maximized and then switches to something like a 7:2 ratio. > When it is > maximized and then unmaximized, it never returns to its original size. Keeping track of the window size prior to maximization and restoring it on unminimize is the window manager's job. However if no windows besides Firefox are affected, I wouldn't exclude a bug there. Maybe some rogue add-on? > 2. Random rearrangement of icons on the desktop: > I have organized my current projects and things to do in a dozen folders on > my desktop, arranged in a grid. So far, this has happened to me three times: > Upon logging in, some of them were taken out of the grid and randomly placed > all over the desktop. The desktop window is provided by nautilus. > 3. Icon inconsistencies in the message tray: > Some icons are 48x48, others 22x22 and others are not displayed at all. In > this screenshot > https://alexpl.fedorapeople.org/screenshots/gnome_message_tray.png > there are actually 8 icons: a seahorse notification that a signature was > good, solaar, dropbox (I don't know if our package is to blame or theirs), > mail-notification, spideroak, gnote, nut monitor and easystroke. This is a (known) gnome-shell issue. I'm afraid the notification changes won't really affect this (other than: "it was wrong to pretend those were notifications, let's decouple them again"), but reporting it again is probably not too useful anyway. > 4. Settings migration was inconsistent: > While most of my settings from the previous version of GNOME were preserved > after the upgrade to 3.14.2, others were not; e.g. the window action key was > preserved, middle click on the titlebar to lower a window wasn't. This is probably not a bug. The default of the middle-click-on-titlebar setting was changed, so unless you explicitly changed the setting before, it is expected that you get the new default rather than preserving the default value from time of installation. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME glitches in F21 - Should they be reported and against which components?
On Mon, Jan 26, 2015 at 5:23 PM, Alexander Ploumistos wrote: > On Mon, Jan 26, 2015 at 5:29 PM, Florian Müllner > wrote: >> > After a little bit of testing, I can confirm that it happens with every app. > [...] > Do I file this against mutter? Yes please. >> The desktop window is provided by nautilus. > > > Should I file a bug, when I don't have a way to reproduce this behavior? Can't hurt. > So these icons will remain in the message tray or will they be moved to the > top bar notification area? That's not entirely clear yet, they will probably be moved to a dedicated area (possibly some kind of drawer). They will definitively not be mixed with the system status area in the top bar. > From GNOME's own icons, I gather that 48x48 is the default size. Seahorse > was problematic since F19, mail notification and solaar icons were 48x48 in > F20, easystroke's icon was visible in F20 (same package version as currently > in F21), dropbox and spideroak were at 22x22 (I think). Do I bother the > maintainers, or do I leave them be? No, at least not for legacy status icons, as that's a gnome-shell issue. Though from the listing above, at least seahorse should use "proper" notifications? I am not aware of any reported issues with those, so that's worth filing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: OpenH264 in Fedora
On Sat, Nov 2, 2013 at 4:11 PM, Gregory Maxwell wrote: > The intention is that any parties capable of obtaining and running the > provided binaries[...] can have a fully licensed > implementation of H.264 at no cost. IANAL, but I am sure that this will not be included in any official Fedora repository. Including a binary package not built on Fedora infrastructure is not an option, and building a package from the provided source code is not covered by the patent license. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Mon, Nov 4, 2013 at 11:03 AM, drago01 wrote: > Firefox for instance could use that, or libreoffice, or eclipse. If a > user needs a newer version (or nightly build) without having upstream > worry about the specific distribution. ... or users having to update their *entire* system to unstable/experimental versions if they want to try the lastest Firefox/Libreoffice/Eclipse -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Mon, Nov 4, 2013 at 11:37 AM, Nicolas Mailhot < nicolas.mail...@laposte.net> wrote: > GNOME decided to break it all the time (can't even get extensions work > from one gnome-shell version to the next one and no gracefully disabling > is still functional breakage). So what do you suggest? We can either (1) restrict the functionality extension can provide (e.g. "add an icon with a menu to the top bar" - of course that'd mean no alternate-tab, shell-shape, alternative-status-menu etc.) (2) cease development of gnome-shell (1) will cause an understandable outrage as it would mean the end for a large percentage of extensions, and (2) is not an option. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Mon, Nov 4, 2013 at 6:57 PM, Kevin Kofler wrote: > Florian Müllner wrote: >> ... or users having to update their *entire* system to >> unstable/experimental versions if they want to try the lastest >> Firefox/Libreoffice/Eclipse > > Then either upstream or the Fedora packager should just build the unstable > version against the stable Fedora in a PPA. See e.g. kde-unstable for KDE > betas. This does not work if the unstable package depends on an unstable version of a dependency shared with the stable system, e.g. if kate depends on an experimental Qt version, your current choice is to not test it or have all of KDE use an unstable version of Qt. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 7, 2013 at 4:58 PM, Kevin Kofler wrote: > (My guess: Canonical will come up with their own Ubuntu App model requiring > Ubuntu technologies If you had read Lennart's previous reply to this thread, you'd be aware that they already did. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: unaccessability
On Thu, Nov 7, 2013 at 6:36 PM, Rahul Sundaram wrote: > Perhaps instead of ignoring them entirely, you can just sort the results or > having > a secondary view "Click here for command line applications that match your > search > results" etc can be considered. I guess the main obstacle here is that there isn't really a good criterion which is as clear-cut as "installs a (non-NoDisplay) .desktop file" => "this is a user-visible gui application" for gui applications - mutt certainly is a user application, sshd clearly is not, zsh ... maybe? "installs an executable in PATH (no libraries, libexec helpers) and does not install a .service file (no system services)" would still consider /usr/bin/X a command line application ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Backports of fixes from F32 -> F31?
Hey, On Thu, Apr 30, 2020 at 09:30, Alex Scheel wrote: And yeah, agreed. Backports are time consuming. But this is F31, not F30. There's at least another 6 months of support on this distro (technically...) and as referenced on that ticket, I'm not the only one that has hit it; there's about 10 people CC'd or replying saying they're affected. Plus -- all I'm looking for is a yes/no. Is that too much to ask a maintainer? :-) I'm afraid F31 does usually lose out to upstream/rawhide, RHEL 7, RHEL 8 and F32, sorry :-( But regarding this particular issue, Olivier was kind enough to backport his fix upstream and I rolled another old-stable release. The update is now available at https://bodhi.fedoraproject.org/updates/FEDORA-2020-d29c22c817, testing and karma are appreciated. Regards, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
Hey, On Sun, Feb 18, 2018 at 6:09 PM, Igor Gnatenko wrote: > List of packages and respective maintainers: > https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt Done: gnome-session gnome-shell-extensions(*) Cheers, Florian (*) accidentally, by changing build systems to meson which insists less on a cc dependency ... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
mutter soname bump
Mutter 48.alpha, the first development release of the upcoming GNOME 48, was released on Monday. As usual, this changes both the API version (mutter-15 → mutter-16) and the soname of libmutter. This should affect the following packages: - gnome-shell - gnome-kiosk - gala The f42-build-side-103564, side tag already has builds of mutter, gnome-shell and gnome-kiosk. gala still needs to be updated to support the new version. I've spoken to one of the upstream maintainers, and they promised to get to it soon; however they also indicated that they "usually wait for it to appear in rawhide". So unless there are strong objections, I will file the update soon. Regards, Florian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
