New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Start readying 10.3 #800

Closed
ikeydoherty opened this Issue Feb 12, 2017 · 41 comments

Comments

Projects
None yet
10 participants
@ikeydoherty
Member

ikeydoherty commented Feb 12, 2017

master is currently very sore and likely broken, because we went and nuked autotools, replacing it with meson.

We need to remove methods not available in older Meson for other distros, like get_pkgconfig_variable, before we can do a 10.3. Likewise, we also need to dump the vala budgie-wm (which in turn solves this variable issue) and put the C code back in.

Also need people to test that I didn't completely balls things up with the conversion, fix up symbol visibility, etc.

10.3 Base Requirements (subject to change)

  • Fix the GNOME 3.22 regressions (stumpy rundialog, etc.)
  • Ensure others can build against Budgie tree
  • For the love of all that is holy, throw a working graphical alt+tab into the budgie-wm
  • Sync natray with gnome-panel changes
  • Cleanup natray implementation
  • Sync GVC
  • Sync translations
@Krutonium

This comment has been minimized.

Show comment
Hide comment
@Krutonium

Krutonium Feb 13, 2017

Ah, so this is why pacaur was unable to build. Good Luck!

Krutonium commented Feb 13, 2017

Ah, so this is why pacaur was unable to build. Good Luck!

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Feb 13, 2017

Member

@PFCKrutonium the reason why it wasn't able to build is that nobody reviews Arch packages and they think following git master is a good thing. It should be actively maintained and set to each new working tag/commit, once someone has checked it.

As it stands, Arch .. packages.. Whatever. Is what it is. What I need is people testing the changes and helping us validate them.

Is there some way people can make it known when installing budgie-desktop-git that things are currently in flux and may eat your hamster?

Member

ikeydoherty commented Feb 13, 2017

@PFCKrutonium the reason why it wasn't able to build is that nobody reviews Arch packages and they think following git master is a good thing. It should be actively maintained and set to each new working tag/commit, once someone has checked it.

As it stands, Arch .. packages.. Whatever. Is what it is. What I need is people testing the changes and helping us validate them.

Is there some way people can make it known when installing budgie-desktop-git that things are currently in flux and may eat your hamster?

@Krutonium

This comment has been minimized.

Show comment
Hide comment
@Krutonium

Krutonium Feb 13, 2017

Perhaps if you contact the package maintainer, they could have it drop that message before building? In flashing text, if need be? Honestly I only tried the git version because I was curious, I stick to the stable build usually.

And I am not sure what to call an AUR package, short of well, a Package. I suppose you could call it a PKGBUILD...?

Krutonium commented Feb 13, 2017

Perhaps if you contact the package maintainer, they could have it drop that message before building? In flashing text, if need be? Honestly I only tried the git version because I was curious, I stick to the stable build usually.

And I am not sure what to call an AUR package, short of well, a Package. I suppose you could call it a PKGBUILD...?

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Feb 13, 2017

Member

It's not really up to me to contact the package maintainers now is it :P It's up to them to ensure their packages are reproducible and sane, and stay abreast of upstream developments. And I don't use Arch either so those are circles I don't walk in (I haven't a clue who is maintainer).

Upstream engagement happens here, and on IRC.

Member

ikeydoherty commented Feb 13, 2017

It's not really up to me to contact the package maintainers now is it :P It's up to them to ensure their packages are reproducible and sane, and stay abreast of upstream developments. And I don't use Arch either so those are circles I don't walk in (I haven't a clue who is maintainer).

Upstream engagement happens here, and on IRC.

@Krutonium

This comment has been minimized.

Show comment
Hide comment
@Krutonium

Krutonium Feb 13, 2017

I dropped a line to the maintainer with a link here, so hopefully that will allow more direct contact.

Krutonium commented Feb 13, 2017

I dropped a line to the maintainer with a link here, so hopefully that will allow more direct contact.

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Feb 13, 2017

Member

FWIW we do have an IRC channel to make shit like this easier :P

Member

ikeydoherty commented Feb 13, 2017

FWIW we do have an IRC channel to make shit like this easier :P

@ricardomv

This comment has been minimized.

Show comment
Hide comment
@ricardomv

ricardomv Feb 13, 2017

Contributor

@ikeydoherty I am the package maintainer of budgie-desktop-git in the AUR and what you are asking is impossible, i can't review every commit you make, the most i could do is check if everything builds in each release, but for that we have the package budgie-desktop in the main repositories. I usually keep an eye on changes here and try to fix the PKGBUILD. If i'm not mistaken the build broke less than 24h ago so i'm not that late.

Contributor

ricardomv commented Feb 13, 2017

@ikeydoherty I am the package maintainer of budgie-desktop-git in the AUR and what you are asking is impossible, i can't review every commit you make, the most i could do is check if everything builds in each release, but for that we have the package budgie-desktop in the main repositories. I usually keep an eye on changes here and try to fix the PKGBUILD. If i'm not mistaken the build broke less than 24h ago so i'm not that late.

@fossfreedom

This comment has been minimized.

Show comment
Hide comment
@fossfreedom

fossfreedom Feb 13, 2017

Contributor

@ricardomv probably better to discuss on IRC as Ikey has indicated - #budgie-desktop-dev on freenode

Contributor

fossfreedom commented Feb 13, 2017

@ricardomv probably better to discuss on IRC as Ikey has indicated - #budgie-desktop-dev on freenode

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Feb 13, 2017

Member

Are we being serious here? :P I manage an entire distro and make sure every package builds. What I'm pointing out is that aiming a package at a moving target is always going to fuck up. I've not asked you to check every commit, you're exaggerating there. What's wrong with sync+check of the package every couple of weeks?

The master branch is supposed to be where I can make breaking changes. The problem I have is that everytime I break anything on master, I'm getting a bug report about it. It's supposed to break :P

Member

ikeydoherty commented Feb 13, 2017

Are we being serious here? :P I manage an entire distro and make sure every package builds. What I'm pointing out is that aiming a package at a moving target is always going to fuck up. I've not asked you to check every commit, you're exaggerating there. What's wrong with sync+check of the package every couple of weeks?

The master branch is supposed to be where I can make breaking changes. The problem I have is that everytime I break anything on master, I'm getting a bug report about it. It's supposed to break :P

@ricardomv

This comment has been minimized.

Show comment
Hide comment
@ricardomv

ricardomv Feb 13, 2017

Contributor

@ikeydoherty if i did what you are asking every couple of weeks i would get the package flagged as out of date. I see we have different opinion of what a master branch should be, i think things should break in branches and only merged to master (production) when tested and working (at least for the developer).

Contributor

ricardomv commented Feb 13, 2017

@ikeydoherty if i did what you are asking every couple of weeks i would get the package flagged as out of date. I see we have different opinion of what a master branch should be, i think things should break in branches and only merged to master (production) when tested and working (at least for the developer).

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Feb 13, 2017

Member

No, that's what tags are for. Stable releases. When I'm ready to cut a release I create a tag, tarballs, release notes, etc. If master was meant to always be stable then what would be the point in tags?
And with all due respect your opinion on what it should and shouldn't be isn't applicable here, I'm the one creating Budgie :)

Large changes are done in feature branches, and when working in a multiperson project, it is expected that the master branch build without issues. Budgie doesn't have multiple people committing code each day, it has me. So I ensure that master builds. That does not mean ready to use or stable. When they are, we tag a new release. Basic release engineering practices.

Member

ikeydoherty commented Feb 13, 2017

No, that's what tags are for. Stable releases. When I'm ready to cut a release I create a tag, tarballs, release notes, etc. If master was meant to always be stable then what would be the point in tags?
And with all due respect your opinion on what it should and shouldn't be isn't applicable here, I'm the one creating Budgie :)

Large changes are done in feature branches, and when working in a multiperson project, it is expected that the master branch build without issues. Budgie doesn't have multiple people committing code each day, it has me. So I ensure that master builds. That does not mean ready to use or stable. When they are, we tag a new release. Basic release engineering practices.

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Feb 13, 2017

Member

You can solve this non-issue quite easily by making it obvious to users of your package that it can break at any time, and should be considered an unstable package. What I'm not doing is jumping on the bandwagon of some github-based developers who lack any discipline for release practices and instead assume everyone can just run from git and be OK, without ever issuing a proper release. I deal with those people constantly in Solus, and often those packages are rejected because the developer doesn't have a fundamental grasp of software development, and lacks deployment discipline. That mindset is further reenforced by so-called "git packages", where they really expect actual users (not hackers, hobbyists, enthusiasts) to run from git without consequence. It's a self defeating relationship.

Member

ikeydoherty commented Feb 13, 2017

You can solve this non-issue quite easily by making it obvious to users of your package that it can break at any time, and should be considered an unstable package. What I'm not doing is jumping on the bandwagon of some github-based developers who lack any discipline for release practices and instead assume everyone can just run from git and be OK, without ever issuing a proper release. I deal with those people constantly in Solus, and often those packages are rejected because the developer doesn't have a fundamental grasp of software development, and lacks deployment discipline. That mindset is further reenforced by so-called "git packages", where they really expect actual users (not hackers, hobbyists, enthusiasts) to run from git without consequence. It's a self defeating relationship.

@jbicha

This comment has been minimized.

Show comment
Hide comment
@jbicha

jbicha Feb 13, 2017

Why is there a budgie-desktop-git package? Is there that much demand for a desktop that has a good chance of being broken on updates?

Are these -git packages common in Arch?

jbicha commented Feb 13, 2017

Why is there a budgie-desktop-git package? Is there that much demand for a desktop that has a good chance of being broken on updates?

Are these -git packages common in Arch?

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Feb 13, 2017

Member

As a final note on the issue:

i would get the package flagged as out of date

The problem here isn't how things are built in Solus, or in Budgie, it's a cultural expectation within Arch Linux. As such it makes it even more important to new people coming across those packages that, yknow, this isn't the stable route, and here be dragons. That way everyone is happy, and I don't get bugs because for whatever reason the package is running make check (when we don't have a test suite, that's .mo file testing)

Member

ikeydoherty commented Feb 13, 2017

As a final note on the issue:

i would get the package flagged as out of date

The problem here isn't how things are built in Solus, or in Budgie, it's a cultural expectation within Arch Linux. As such it makes it even more important to new people coming across those packages that, yknow, this isn't the stable route, and here be dragons. That way everyone is happy, and I don't get bugs because for whatever reason the package is running make check (when we don't have a test suite, that's .mo file testing)

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Feb 13, 2017

Member

@jbicha they're very, very common. From one side of it, sure, I can see the appeal when there is some problem that is fixed in git that isn't in a release yet, or because there is some shiny new feature, but this can be broadly categorised as:

  • If we have a fix in git, and we've not yet managed a release, backport the fix to your relevant distro package (Much like you guys do in Ubuntu, ty)
  • If its "cool new feature" that isn't a fix, it qualifies as enthusiast interest, and not a generally supportable configuration.
Member

ikeydoherty commented Feb 13, 2017

@jbicha they're very, very common. From one side of it, sure, I can see the appeal when there is some problem that is fixed in git that isn't in a release yet, or because there is some shiny new feature, but this can be broadly categorised as:

  • If we have a fix in git, and we've not yet managed a release, backport the fix to your relevant distro package (Much like you guys do in Ubuntu, ty)
  • If its "cool new feature" that isn't a fix, it qualifies as enthusiast interest, and not a generally supportable configuration.
@ricardomv

This comment has been minimized.

Show comment
Hide comment
@ricardomv

ricardomv Feb 13, 2017

Contributor

Yes i am not telling you how to do you job i'm just giving my opinion that you are free to ignore.
This is getting a bit out of topic but i used the git package as a developer to find bugs and for the easy setup on a machine that is not my main develop environment. That being said i think you only have to win with the more people have the latest revision installed and can report bugs before a major release.

Contributor

ricardomv commented Feb 13, 2017

Yes i am not telling you how to do you job i'm just giving my opinion that you are free to ignore.
This is getting a bit out of topic but i used the git package as a developer to find bugs and for the easy setup on a machine that is not my main develop environment. That being said i think you only have to win with the more people have the latest revision installed and can report bugs before a major release.

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Feb 13, 2017

Member

Right, so developer, bughunting, enthusiast level bits, it's a cool thing to have. But I think we do need a set of guidelines on this, as basically it doesn't matter by who, where, or at what level, if something Budgie related is fucking up, it's me that gets it in the ear, and Budgie that looks bad as a result.

I think we need to basically limit the validity of AUR bug reports significantly, and prefer that they're discussed on IRC first. Also I'm highly aware that many of those bugs are never reported to me until it fails to build, the issues are generally left on the forum or the AUR for me to have to go and find later. :P

So:

  • General build failures, probably best to collab with yourself and ping me on #budgie-desktop-dev on IRC
  • If in doubt, IRC first.

Given the enthusiast/developer targeting of the package, it's not a lot of good if people don't actually turn up to engage and discuss the issues, and then we find out that "oh its been like this for months". Engagement, all around :P

If anyone has any other general bits of policy/thoughts they wanna throw in - may as well do it now so we can get all this cruft in order before the next release

Member

ikeydoherty commented Feb 13, 2017

Right, so developer, bughunting, enthusiast level bits, it's a cool thing to have. But I think we do need a set of guidelines on this, as basically it doesn't matter by who, where, or at what level, if something Budgie related is fucking up, it's me that gets it in the ear, and Budgie that looks bad as a result.

I think we need to basically limit the validity of AUR bug reports significantly, and prefer that they're discussed on IRC first. Also I'm highly aware that many of those bugs are never reported to me until it fails to build, the issues are generally left on the forum or the AUR for me to have to go and find later. :P

So:

  • General build failures, probably best to collab with yourself and ping me on #budgie-desktop-dev on IRC
  • If in doubt, IRC first.

Given the enthusiast/developer targeting of the package, it's not a lot of good if people don't actually turn up to engage and discuss the issues, and then we find out that "oh its been like this for months". Engagement, all around :P

If anyone has any other general bits of policy/thoughts they wanna throw in - may as well do it now so we can get all this cruft in order before the next release

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Feb 13, 2017

Member

Also, to lighten the mood, here's a compilation of cute kittens:

Compilation of cute kittens

Member

ikeydoherty commented Feb 13, 2017

Also, to lighten the mood, here's a compilation of cute kittens:

Compilation of cute kittens

@ricardomv

This comment has been minimized.

Show comment
Hide comment
@ricardomv

ricardomv Feb 13, 2017

Contributor

OHhhhh :D

Contributor

ricardomv commented Feb 13, 2017

OHhhhh :D

@Flat

This comment has been minimized.

Show comment
Hide comment
@Flat

Flat Feb 13, 2017

I'd like to point out that *-git packages in the aur should not, and are definitely pointed out by the community to not be used as stable packages.

That being said aur packages are not official packages, they are user contributed. Arch Linux does have stable budgie-desktop packages (Which are currently on version 10.2.9). These packages are the ones that follow the tagged releases. *-git packages on the aur will always be the tip of master. EDIT: Also wanted to add that aur packages cannot mirror official packages, for example there can't be an aur package for budgie-desktop that also builds the tags or release versions.

I'm not sure why everyday users would use the aur git package over the distro packages. I would expect the only users of the git version would be those actively trying to support budgie development by testing the code and or contributing themselves; or those that feel the release is missing a new feature they need that was recently committed.

If people having issues using git master is well, enough of an issue, you could require all bug reports to be using the latest tagged version.

Just my opinion on the subject as an Arch user.

Keep up the good work, and cute kittens.

Flat commented Feb 13, 2017

I'd like to point out that *-git packages in the aur should not, and are definitely pointed out by the community to not be used as stable packages.

That being said aur packages are not official packages, they are user contributed. Arch Linux does have stable budgie-desktop packages (Which are currently on version 10.2.9). These packages are the ones that follow the tagged releases. *-git packages on the aur will always be the tip of master. EDIT: Also wanted to add that aur packages cannot mirror official packages, for example there can't be an aur package for budgie-desktop that also builds the tags or release versions.

I'm not sure why everyday users would use the aur git package over the distro packages. I would expect the only users of the git version would be those actively trying to support budgie development by testing the code and or contributing themselves; or those that feel the release is missing a new feature they need that was recently committed.

If people having issues using git master is well, enough of an issue, you could require all bug reports to be using the latest tagged version.

Just my opinion on the subject as an Arch user.

Keep up the good work, and cute kittens.

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Feb 13, 2017

Member

@Flat that's mostly in line with how I assumed the -git packages to be. The main thing from my viewpoint is that people must expect that master can break at any given minute (Though with the facts in hand obviously I'll keep that in mind) - so don't be surprised when it becomes impossible to build at some point in time.. ^^

Member

ikeydoherty commented Feb 13, 2017

@Flat that's mostly in line with how I assumed the -git packages to be. The main thing from my viewpoint is that people must expect that master can break at any given minute (Though with the facts in hand obviously I'll keep that in mind) - so don't be surprised when it becomes impossible to build at some point in time.. ^^

@adamjameschristensen

This comment has been minimized.

Show comment
Hide comment
@adamjameschristensen

adamjameschristensen Feb 16, 2017

FWIW: I use Arch and follow the -git package, but never assume it will "just work". That's just life on the bleeding edge. I always make sure my kittens (and any nearby hamsters) are out of harms way before attempting to compile!

adamjameschristensen commented Feb 16, 2017

FWIW: I use Arch and follow the -git package, but never assume it will "just work". That's just life on the bleeding edge. I always make sure my kittens (and any nearby hamsters) are out of harms way before attempting to compile!

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Feb 16, 2017

Member

Ironic that we're hiding kittens from a Budgie xD

Member

ikeydoherty commented Feb 16, 2017

Ironic that we're hiding kittens from a Budgie xD

@JoshStrobl JoshStrobl added this to the 10.3 milestone Feb 28, 2017

ikeydoherty added a commit that referenced this issue Apr 7, 2017

gvc: Sync with upstream per issue #800
This is now synced with commit ce8e4880ce31e275c40825c4ed756c791107f810

Signed-off-by: Ikey Doherty <ikey@solus-project.com>
@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Apr 7, 2017

Member

gvc now synced with ce8e4880ce31e275c40825c4ed756c791107f810

Member

ikeydoherty commented Apr 7, 2017

gvc now synced with ce8e4880ce31e275c40825c4ed756c791107f810

ikeydoherty added a commit that referenced this issue Apr 7, 2017

Revert "wm: Restore C version to continue hacking on this" (issue #800)
This reverts commit 5096925.

C WM is no longer a target. I'm not going to waste my time doing a complete
rewrite, only to do another rewrite for Budgie 11. This is just a poor time
investment. Instead we'll try to plug something in and clean it all up to
make it last for a while.
@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Apr 7, 2017

Member

Removing C WM target as it's a complete waste of time + resources

Member

ikeydoherty commented Apr 7, 2017

Removing C WM target as it's a complete waste of time + resources

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Apr 7, 2017

Member

Removed target for backporting meson as @fossfreedom said it wouldn't be an issue

Member

ikeydoherty commented Apr 7, 2017

Removed target for backporting meson as @fossfreedom said it wouldn't be an issue

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Apr 7, 2017

Member

Removed target for fixing "noisy vala compilation warnings" because Vala is a fucking mess.

Member

ikeydoherty commented Apr 7, 2017

Removed target for fixing "noisy vala compilation warnings" because Vala is a fucking mess.

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Apr 7, 2017

Member

Removed target for "symbol visibility" for the aforementioned reason.

Member

ikeydoherty commented Apr 7, 2017

Removed target for "symbol visibility" for the aforementioned reason.

@Krutonium

This comment has been minimized.

Show comment
Hide comment
@Krutonium

Krutonium Apr 8, 2017

I'm curious: Just how much work remains to be done? I mean, obviously only 1 checkmark is done, but I don't know the amount of work each check represents.

Krutonium commented Apr 8, 2017

I'm curious: Just how much work remains to be done? I mean, obviously only 1 checkmark is done, but I don't know the amount of work each check represents.

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Apr 8, 2017

Member

I only started ticking them off last night and I'm mainly just focusing on alt+tab tbh.
I want to get 10.3 done and dusted, because with 11 looming, 10.x is starting to represent wasted investment. And I seriously, seriously hate Vala at this point.

I just wanna get 10.3 out, never look at the code again, and focus all my efforts on an amazing Budgie 11.

Member

ikeydoherty commented Apr 8, 2017

I only started ticking them off last night and I'm mainly just focusing on alt+tab tbh.
I want to get 10.3 done and dusted, because with 11 looming, 10.x is starting to represent wasted investment. And I seriously, seriously hate Vala at this point.

I just wanna get 10.3 out, never look at the code again, and focus all my efforts on an amazing Budgie 11.

@KloudKoder

This comment has been minimized.

Show comment
Hide comment
@KloudKoder

KloudKoder Apr 13, 2017

The real problem with the current alt+tab situation, which is why I took the time to write this, is that it doesn't seem to remember sequence. Let's say I open task A, then B, then C. Now I hit alt+tab. I expect to be switched back to task B. It seems to do that now. But then I should have two choices: either take my finger off alt, or leave it depressed. In the first case, the next time I hit alt+tab, I expect to return to task C. In the second, I expect to get back to task A. This is how Windows worked for a long time, although they may have changed it. It just makes intuitive sense because in the first case, you're just flipping between windows trying to copypaste from one app to another or otherwise coordinate them. In the second case, you're basically using the task switcher like a crude browser to find that MP3 window you had up an hour ago.

If we got a bunch of thumbnails of windows on a rotating task switcher, that would be great. It would come up when you press alt, and disappear when you release alt. Hopefully these thumbnails would also be tagged with the window title (and not in a latent way where you need to hover for a while to see it). One other thing is that hotkeys would be useful (optional single keystoke instead of lots of tab hits), but only if a given task owns its hotkey until it gets closed, so they don't all change every time a new task is created. Simple, intuitive, and fast.

KloudKoder commented Apr 13, 2017

The real problem with the current alt+tab situation, which is why I took the time to write this, is that it doesn't seem to remember sequence. Let's say I open task A, then B, then C. Now I hit alt+tab. I expect to be switched back to task B. It seems to do that now. But then I should have two choices: either take my finger off alt, or leave it depressed. In the first case, the next time I hit alt+tab, I expect to return to task C. In the second, I expect to get back to task A. This is how Windows worked for a long time, although they may have changed it. It just makes intuitive sense because in the first case, you're just flipping between windows trying to copypaste from one app to another or otherwise coordinate them. In the second case, you're basically using the task switcher like a crude browser to find that MP3 window you had up an hour ago.

If we got a bunch of thumbnails of windows on a rotating task switcher, that would be great. It would come up when you press alt, and disappear when you release alt. Hopefully these thumbnails would also be tagged with the window title (and not in a latent way where you need to hover for a while to see it). One other thing is that hotkeys would be useful (optional single keystoke instead of lots of tab hits), but only if a given task owns its hotkey until it gets closed, so they don't all change every time a new task is created. Simple, intuitive, and fast.

@m-delvalle

This comment has been minimized.

Show comment
Hide comment
@m-delvalle

m-delvalle Apr 13, 2017

At the risk of hijacking this conversation: if you guys are going for the "animated" alt+tab, please make it "optional" through settings.

I agree with the first paragraph in previous comment, given I often find myself expecting Solus to behave like Windows when alt-tabbing... But for heavy using, having an animated transition can get annoying really fast 😒

Maybe have a nice, slick, animated exposé-like/workspace animation, and a fast, unobtrusive, laim alt+tab window switcher 👍

m-delvalle commented Apr 13, 2017

At the risk of hijacking this conversation: if you guys are going for the "animated" alt+tab, please make it "optional" through settings.

I agree with the first paragraph in previous comment, given I often find myself expecting Solus to behave like Windows when alt-tabbing... But for heavy using, having an animated transition can get annoying really fast 😒

Maybe have a nice, slick, animated exposé-like/workspace animation, and a fast, unobtrusive, laim alt+tab window switcher 👍

@KloudKoder

This comment has been minimized.

Show comment
Hide comment
@KloudKoder

KloudKoder Apr 13, 2017

Yeah m-delvalle, animated task switchers are more hindrance than help. They look great, but the rendering can be quite taxing on memory and cache contents. It's not the act of scrolling through all those screen shots of tasks that's the worst part; it's the rendering to begin with, which requires a screen shot every time you switch away from a task, or worse, at some periodic interval that burns up the battery and keeps the machine awake. And then there's the question of how stale screen shots should be allowed to get. If they're too stale, then someone might mistakenly think that their background task isn't done, when in fact it is. The more I think about it, the more I think we should just stick with icons. We should have titles below them, and hopefully hotkeys, but no more than that. It would be really wonderful if they were sorted from most to least recently active. (This really matters when you have lots of instances of the same task open, and need to know which is which, but it's not obvious because all the titles are the same and/or the screen shots very similar.) And let's not forget shift+alt+tab to move backwards, just for the sake of intuitiveness.

KloudKoder commented Apr 13, 2017

Yeah m-delvalle, animated task switchers are more hindrance than help. They look great, but the rendering can be quite taxing on memory and cache contents. It's not the act of scrolling through all those screen shots of tasks that's the worst part; it's the rendering to begin with, which requires a screen shot every time you switch away from a task, or worse, at some periodic interval that burns up the battery and keeps the machine awake. And then there's the question of how stale screen shots should be allowed to get. If they're too stale, then someone might mistakenly think that their background task isn't done, when in fact it is. The more I think about it, the more I think we should just stick with icons. We should have titles below them, and hopefully hotkeys, but no more than that. It would be really wonderful if they were sorted from most to least recently active. (This really matters when you have lots of instances of the same task open, and need to know which is which, but it's not obvious because all the titles are the same and/or the screen shots very similar.) And let's not forget shift+alt+tab to move backwards, just for the sake of intuitiveness.

@KloudKoder

This comment has been minimized.

Show comment
Hide comment
@KloudKoder

KloudKoder Apr 13, 2017

Actually what if we just made alt+tab toggle the switcher to and from the focus? Then you hit "1" for the most recently accessed task, "2" for the second most recent, etc. (We could use letters too, but there might be some internationalization considerations there.) This would help a lot when you have like 20 tasks open, as I often do. I mean, how many times do you want to hit tab?

KloudKoder commented Apr 13, 2017

Actually what if we just made alt+tab toggle the switcher to and from the focus? Then you hit "1" for the most recently accessed task, "2" for the second most recent, etc. (We could use letters too, but there might be some internationalization considerations there.) This would help a lot when you have like 20 tasks open, as I often do. I mean, how many times do you want to hit tab?

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Apr 14, 2017

Member

Please see: https://plus.google.com/+Solus-Project/posts/PeLrYkNqBFv

Putting a €500 bounty up if someone can implement this for the weekend (alt+tab)
Details in the post

Member

ikeydoherty commented Apr 14, 2017

Please see: https://plus.google.com/+Solus-Project/posts/PeLrYkNqBFv

Putting a €500 bounty up if someone can implement this for the weekend (alt+tab)
Details in the post

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Apr 15, 2017

Member

Alt+Tab is now merged thanks to community work, now cleaning it up

Member

ikeydoherty commented Apr 15, 2017

Alt+Tab is now merged thanks to community work, now cleaning it up

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Apr 16, 2017

Member

natray stuff now done, works better too

Member

ikeydoherty commented Apr 16, 2017

natray stuff now done, works better too

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Apr 16, 2017

Member

Added support (#718) for switching button layouts

Member

ikeydoherty commented Apr 16, 2017

Added support (#718) for switching button layouts

@ikeydoherty ikeydoherty removed this from the 10.3 milestone Apr 16, 2017

@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Apr 16, 2017

Member

Deleted largely unhelpful 10.3 milestone so i can focus it all here.

Member

ikeydoherty commented Apr 16, 2017

Deleted largely unhelpful 10.3 milestone so i can focus it all here.

ikeydoherty added a commit that referenced this issue Apr 16, 2017

Ensure pkg-config includes budgie-desktop directory (issue #800)
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
@ikeydoherty

This comment has been minimized.

Show comment
Hide comment
@ikeydoherty

ikeydoherty Apr 16, 2017

Member

We're able to build against the tree again as verified with vala-panel-appmenu with git version of Budgie Desktop: https://build.solus-project.com/logs/vala-panel-appmenu-0.4.4-1.log

Member

ikeydoherty commented Apr 16, 2017

We're able to build against the tree again as verified with vala-panel-appmenu with git version of Budgie Desktop: https://build.solus-project.com/logs/vala-panel-appmenu-0.4.4-1.log

ikeydoherty added a commit that referenced this issue Apr 16, 2017

po: Sync for 10.3 and freeze strings per issue #800
Signed-off-by: Ikey Doherty <ikey@solus-project.com>

ikeydoherty added a commit that referenced this issue Apr 16, 2017

rundialog: Fix stumpy rundialog syndrome (issue #800)
Astonishingly this "regression" is because GTK fixed something that
made the original size request actually start working. Turns out, our
requested size was way too small :P

Signed-off-by: Ikey Doherty <ikey@solus-project.com>
@JoshStrobl

This comment has been minimized.

Show comment
Hide comment
@JoshStrobl

JoshStrobl Apr 28, 2017

Member

With Run Dialog issue being resolved, closing task. Thank you to all the community contributions that have helped make Budgie 10.3 a reality. ❤️

Member

JoshStrobl commented Apr 28, 2017

With Run Dialog issue being resolved, closing task. Thank you to all the community contributions that have helped make Budgie 10.3 a reality. ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment