Start readying 10.3

[ikeydoherty]

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)

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

[Krutonium]

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

[ikeydoherty]

@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]

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]

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]

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

[ikeydoherty]

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

[ricardomv]

@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]

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

[ikeydoherty]

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]

@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]

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]

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]

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]

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]

@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]

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]

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]

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

[ricardomv]

OHhhhh :D

[Flat]

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]

@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]

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]

Ironic that we're hiding kittens from a Budgie xD

[ikeydoherty]

gvc now synced with ce8e4880ce31e275c40825c4ed756c791107f810

[ikeydoherty]

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

[ikeydoherty]

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

[ikeydoherty]

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

[ikeydoherty]

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

[Krutonium]

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]

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]

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]

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 :unamused:

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

[KloudKoder]

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]

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]

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]

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

[ikeydoherty]

natray stuff now done, works better too

[ikeydoherty]

Added support (#718) for switching button layouts

[ikeydoherty]

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

[ikeydoherty]

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

[JoshStrobl]

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