Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

January 30 2018

Peter Hutterer: tuhi - a daemon to support Wacom SmartPad devices

For the last few weeks, Benjamin Tissoires and I have been working on a new project: Tuhi [1], a daemon to connect to and download data from Wacom SmartPad devices like the Bamboo Spark, Bamboo Slate and, eventually, the Bamboo Folio and the Intuos Pro Paper devices. These devices are not traditional graphics tablets plugged into a computer but rather smart notepads where the user's offline drawing is saved as stroke data in vector format and later synchronised with the host computer over Bluetooth. There it can be converted to SVG, integrated into the applications, etc. Wacom's application for this is Inkspace.

There is no official Linux support for these devices. Benjamin and I started looking at the protocol dumps last year and, luckily, they're not completely indecipherable and reverse-engineering them was relatively straightforward. Now it is a few weeks later and we have something that is usable (if a bit rough) and provides the foundation for supporting these devices properly on the Linux desktop. The repository is available on github at https://github.com/tuhiproject/tuhi/.

The main core is a DBus session daemon written in Python. That daemon connects to the devices and exposes them over a custom DBus API. That API is relatively simple, it supports the methods to search for devices, pair devices, listen for data from devices and finally to fetch the data. It has some basic extras built in like temporary storage of the drawing data so they survive daemon restarts. But otherwise it's a three-way mapper from the Bluez device, the serial controller we talk to on the device and the Tuhi DBus API presented to the clients. One such client is the little commandline tool that comes with tuhi: tuhi-kete [2]. Here's a short example:


$> ./tools/tuhi-kete.py
Tuhi shell control
tuhi> search on
INFO: Pairable device: E2:43:03:67:0E:01 - Bamboo Spark
tuhi> pair E2:43:03:67:0E:01
INFO: E2:43:03:67:0E:01 - Bamboo Spark: Press button on device now
INFO: E2:43:03:67:0E:01 - Bamboo Spark: Pairing successful
tuhi> listen E2:43:03:67:0E:01
INFO: E2:43:03:67:0E:01 - Bamboo Spark: drawings available: 1516853586, 1516859506, [...]
tuhi> list
E2:43:03:67:0E:01 - Bamboo Spark
tuhi> info E2:43:03:67:0E:01
E2:43:03:67:0E:01 - Bamboo Spark
Available drawings:
* 1516853586: drawn on the 2018-01-25 at 14:13
* 1516859506: drawn on the 2018-01-25 at 15:51
* 1516860008: drawn on the 2018-01-25 at 16:00
* 1517189792: drawn on the 2018-01-29 at 11:36
tuhi> fetch E2:43:03:67:0E:01 1516853586
INFO: Bamboo Spark: saved file "Bamboo Spark-2018-01-25-14-13.svg"
I won't go into the details because most should be obvious and this is purely a debugging client, not a client we expect real users to use. Plus, everything is still changing quite quickly at this point.

The next step is to get a proper GUI application working. As usual with any GUI-related matter, we'd really appreciate some help :)

The project is young and relying on reverse-engineered protocols means there are still a few rough edges. Right now, the Bamboo Spark and Slate are supported because we have access to those. The Folio should work, it looks like it's a re-packaged Slate. Intuos Pro Paper support is still pending, we don't have access to a device at this point. If you're interested in testing or helping out, come on over to the github site and get started!

[1] tuhi: Maori for "writing, script"
[2] kete: Maori for "kit"

January 29 2018

Fabiano Fidencio: Fleet Commander!

Jeremy Bicha: GNOME Tweaks 3.28 Progress Report 1

A few days ago, I released GNOME Tweaks 3.27.4, a development snapshot on the way to the next stable version 3.28 which will be released alongside GNOME 3.28 in March. Here are some highlights of what’s changed since 3.26.

New Name (Part 2)

For 3.26, we renamed GNOME Tweak Tool to GNOME Tweaks. It was only a partial rename since many underlying parts still used the gnome-tweak-tool name. For 3.28, we have completed the rename. We have renamed the binary, the source tarball releases, the git repository, the .desktop, and app icons. For upgrade compatibility, the autostart file and helper script for the Suspend on Lid Close inhibitor keeps the old name.

New Home

GNOME Tweaks has moved from the classic GNOME Git and Bugzilla to the new GNOME-hosted gitlab.gnome.org. The new hosting includes git hosting, a bug tracker and merge requests. Much of GNOME Core has moved this cycle, and I expect many more projects will move for the 3.30 cycle later this year.

Dark Theme Switch Removed

As promised, the Global Dark Theme switch has been removed. Read my previous post for more explanation of why it’s removed and a brief mention of how theme developers should adapt (provide a separate Dark theme!).

Improved Theme Handling

The theme chooser has been improved in several small ways. Now that it’s quite possible to have a GNOME desktop without any gtk2 apps, it doesn’t make sense to require that a theme provide a gtk2 version to show up in the theme chooser so that requirement has been dropped.

The theme chooser will no longer show the same theme name multiple times if you have a system-wide installed theme and a theme in your user theme directory with the same name. Additionally, GNOME Tweaks does better at supporting the  XDG_DATA_DIRS standard in case you use custom locations to store your themes or gsettings overrides.

GNOME Tweaks 3.27.4 with the HighContrastInverse theme

Finally, gtk3 still offers a HighContrastInverse theme but most people probably weren’t aware of that since it didn’t show up in Tweaks. It does now! It is much darker than Adwaita Dark.

Several of these theme improvements (including HighContrastInverse) have also been included in 3.26.4.

For more details about what’s changed and who’s done the changing, see the project NEWS file.

Sam Thursfield: How BuildStream uses OSTree
Julita Inca: We are back! #LinuXatUNI on the stage
Debarshi Ray: GNOME Photos: an overview of thumbnailing

January 28 2018

Philip Chimento: Geek tip: g_object_new and constructors

January 27 2018

Jo Shields: Hello PGO

Assuming the Planet configuration change was correct, this should be my first post aggregated on Planet GNOME.

Hello!

I’m Jo.

I used to work on Free Software at Collabora, until I sold out, and now I work on Free Software at Microsoft. Specifically, I divide my time between administration of various Xamarin engineering services (primarily the public Jenkins server and its build agents); develop and manage the release of the Mono framework on Windows/Linux and MonoDevelop IDE on Linux; and occasionally work on internal proprietary projects which definitely don’t include Visual Studio Enterprise for Linux. I’m based in the Microsoft office in Cambridge, Mass, along with the Xamarin Release Engineering team, and most of the Xamarin engineering team.

Whilst it hasn’t had the highest profile in the GNOME community for a while, Mono is still out there, in its current niches – in 2018 that would primarily be on smartphones in a wider context, and for games (either via Unity3D or MonoGame/FNA) on the Linux desktop. But hey, it’s still there for desktop apps on Linux if you want it to be! I still use Smuxi as my IRC client. Totally still a thing. And there’s the MonoDevelop IDE, which nowadays I’m trying to release on Linux via Flatpak.

So, um, hi. You’ll see blog posts from me occasionally about Linux software releasing from an ISV perspective, packaging, etc. It’ll be fun for all concerned.

Chandni Verma: Some new problems solved and added to my git repo. last week
Umang Jain: No more hunched back

January 26 2018

Tobias Bernard: Introducing the CSD Initiative

tl;dr: Let’s get rid of title bars. Join the revolution!

Unless you’re one of a very lucky few, you probably use apps with title bars. In case you’ve never come across that term, title bars are the largely empty bars at the top of some application windows. They contain only the window title and a close button, and are completely separate from the window’s content. This makes them very inflexible, as they can not contain any additional UI elements, or integrate with the application window’s content.

Blender, with its badly integrated and pretty much useless title barLuckily, the GNOME ecosystem has been moving away from title bars in favor of header bars. This is a newer, more flexible pattern that allows putting window controls and other UI elements in the same bar. Header bars are client-side decorations (CSD), which means they are drawn by the app rather than the display server. This allows for better integration between application and window chrome.

 

GNOME Builder, an app that makes heavy use of the header bar for UI elements

All GNOME apps (except for Terminal) have moved to header bars over the past few years, and so have many third-party apps. However, there are still a few holdouts. Sadly, these include some of the most important productivity apps people rely on every day (e.g. LibreOffice, Inkscape, and Blender).

There are ways to hide title bars on maximized and tiled windows, but these do not (and will never) work on Wayland (Note: I’m talking about GNOME Shell on Wayland here, not other desktops). All window decorations are client-side on Wayland (even when they look like title bars), so there is no way to hide them at a window manager level.

The CSD Initiative

The only way to solve this problem long-term is to patch applications upstream to not use title bars. So this is what we’ll have to do.

That is why I’m hereby announcing the CSD Initiative, an effort to get as many applications as possible to drop title bars in favor of client-side decorations. This won’t be quick or easy, and will require work on many levels. However, with Wayland already being shipped as the default session by some distros, it’s high time we got started on this.

For a glimpse at what this kind of transition will look like in practice, we can look to Firefox and Chromium. Chromium has recently shipped GNOME-style client-side decorations in v63, and Firefox has them in experimental CSD builds. These are great examples for other apps to follow, as they show that apps don’t have to be 100% native GTK in order to use CSD effectively.

Chromium 63 with CSDChromium 63 with window buttons on the left

What is the goal?

This initiative doesn’t aim to make all apps look and act exactly like native GNOME apps. If an app uses GTK, we do of course want it to respect the GNOME HIG. However, it isn’t realistic to assume that apps like Blender or Telegram will ever look like perfectly native GNOME apps. In these cases, we’re are aiming for functional, not visual consistency. For example, it’s fine if an Electron app has custom close/maximize/minimize icons, as long as they use the same metaphors as the native icons.

Thus, our goal is for as many apps as possible to have the following properites:

  • No title bar
  • Native-looking close/maximize/minimize icons
  • Respects the setting for showing/hiding minimize and maximize
  • Respects the setting for buttons to be on the left/right side of the window

Which apps are affected?

Basically, all applications not using GTK3 (and a few that do use GTK3). That includes GTK2, Qt, and Electron apps. There’s a list of some of the most popular affected apps on this initiative’s Wiki page.

The process will be different for each app, and the changes required will range from “can be done in a weekend” to “holy shit we have to redesign the entire app”. For example, GTK3 apps are relatively easy to port to header bars because they can just use the native GTK component. GTK2 apps first need to be ported to GTK3, which is a major undertaking in itself. Some apps will require major redesigns, because removing the title bar goes hand in hand with moving from old-style menu bars to more modern, contextual menus.

Many Electron apps might be low-hanging fruit, because they already use CSD on macOS. This means it should be possible to make this happen on GNU/Linux as well without major changes to the app. However, some underlying work in Electron to expose the necessary settings to apps might be required first.

Slack, like many Electron apps, uses CSD on macOSThe same Slack app on Ubuntu (with a title bar)

Apps with custom design languages will have to be evaluated on a case-by-case basis. For example, Telegram’s design should be easy to adapt to a header bar layout. Removing the title bar and adding window buttons in the toolbar would come very close to a native GNOME header bar functionally.

Telegram as it looks currently, with a title barTelegram mockup with no title bar

How can I help?

The first step will be making a list of all the apps affected by this initiative. You can add apps to the list on this Wiki page.

Then we’ll need to do the following things for each app:

  1. Talk to the maintainers and convince them that this is a good idea
  2. Do the design work of adapting the layout
  3. Figure out what is required at a technical level
  4. Implement the new layout and get it merged

In addition, we need to evaluate what we can do at the toolkit level to make it easier to implement CSD (e.g. in Electron or Qt apps). This will require lots of work from lots of people with different skills, and nothing will happen overnight. However, the sooner we start, the sooner we’ll live in an awesome CSD-only future.

And that’s where you come in! Are you a developer who needs help updating your app to a header bar layout? A designer who would like to help redesign apps? A web developer who’d like to help make CSD work seamlessly in Electron apps? Come to #gnome-design on IRC/Matrix and talk to us. We can do this!

Happy hacking!

 

Update:

There have been some misunderstandings about what I meant regarding server-side decorations on Wayland. As far as I know (and take this with a grain of salt), Wayland uses CSD by default, but it is possible to add SSD support via protocol extensions. KDE has proposed such a protocol, and support for this protocol has been contributed to GTK by the Sway developers. However, GNOME Shell does not support it and its developers have stated that they have no plans to support it at the moment.

This is what I was referring to by saying that “it will never work on Wayland”. I can see how this could be misinterpreted from the point of view of other desktop environments but that was not my intention, it was simply unfortunate wording. I have updated the relevant part of this post to clarify.

Also, some people seem to have taken from this that we plan on lobbying for removing title bar support from third-party apps in a way that affects other desktops. The goal of this initiative is for GNOME users to get a better experience by having fewer applications with badly integrated title bars on their systems. That doesn’t preclude applications from having title bars on different desktops, or having a preference for this (like Chromium does, for example).

Ruben Vermeersch: Go: debugging multiple response.WriteHeader calls
Christian Schaller: An update on Pipewire – the multimedia revolution
Bastian Ilsø Hougaard: GNOME at FOSDEM 2018 – with socks and more!

January 25 2018

Adrien Plazas: GTK+ Apps on Phones

January 24 2018

Michael Catanzaro: Announcing Epiphany Technology Preview
3272 3e5c
Ismael Olea: I'm going to FOSDEM 2018
Michael Meeks: 2018-01-24 Wednesday

Nuritzi Sanchez: Giving Spotlight | Meet Øyvind Kolås, GEGL maintainer extraordinaire

Last month, we had the pleasure of interviewing Øyvind Kolås, aka “pippin,” about his work on GEGL — a fundamental technology enabling GIMP and GNOME Photos.

GIMP Stickers, CC-BY-SA Michael Natterer

This interview is part of a “Giving Spotlight” series we are doing on some long-time GNOME contributors who have fundraising campaigns. The goal is to help GNOME users understand the importance of the technologies, get to know the maintainers, and learn how to support them.

Without further ado, we invite you to get to know Øyvind and his work on GEGL!

The following interview was conducted over email. 

Getting to know Øyvind

Where are you from and where are you based?

I’m from the town of Ørsta – in the end of a fjord in Norway, but since high-school I’ve been quite migratory. Studying fine art in Oslo and Spain, color science research at a color lab and lecturing multimedia CD-ROM authoring in south-eastern Norway, and working on GNOME technologies like Clutter and cairo for Opened Hand and Intel in London, followed by half a decade of low-budget backpacking. At the moment I am based in Norway – and try to keep in touch with a few people and places – among others England, Germany, and Spain.

Øyvind “pippin” Kolås, CC BY-NC-ND Ross Burton

What do you do and how does it relate to GNOME?

I like tinkering with code – frequently code that involves graphics or UI. This results in sometimes useful, at other times odd, but perhaps interesting, tools, infrastructure, or other software artifacts. Through the years and combined with other interests, this has resulted in contributions to cairo and Clutter, as well as being the maintainer of babl and GEGL, which provide pixel handling and processing machinery for GIMP 2.9, 2.10 and beyond.

How did you first get involved in GNOME?

I attended the second GUADEC which happend in Copenhagen in 2001. This was my first in-person meeting with the people behind nicknames in #gimp as well as meeting in-person GIMP developers and power users, and the wider community around it including the GNOME project.

Why is your fundraising campaign important?

I want GIMP to improve and continue being relevant in the future, as well as
having a powerful graph-based framework for other imaging tasks. I hope that my continued maintainership of babl/GEGL will enable many new and significant workflows in GIMP and related software, as well as provide a foundation for implementing and distributing experimental image processing filters.

Wilber Week 2017, a hackathon for GEGL and GIMP, CC-BY-SA Debarshi Ray

Getting to know GEGL

How did your project originate?

GEGL’s history starts in 1997 with Rythm and Hues studios, a Californian visual effects and animation company. They were experimenting with a 16bit/high bit depth fork of GIMP known as filmgimp/cinepaint. Rythm and Hues succeeded in making GIMP work on high bit depth images, but the internal architecture was found to be lacking – and they started GEGL as a more solid future basis for high bit depth non-destructive editing in GIMP. Their funding/management interest waned, and GEGL development went dormant. GIMP however continued considering GEGL to be its future core.

How did you start working on GEGL?

I’ve been making and using graphics-related software since the early ’90s. In 2003-2004 I made a video editor for my own use in a hobby collaboration music video/short film venture. This video editing project was discontinued and salvaged for spare parts, like babl and a large set of initial operations when I took up maintainership and development of GEGL.

What are some of the greatest challenges that you’ve faced along the way?

When people get to know that I am somehow involved in development of the GIMP project, they expect me to be in control of and responsible for how the UI currently is. I have removed some GIMP menu items in attempts to clean things up and reduce technical debt, but most improvements I can take credit for now, and in the future, are indirect, like how moving to GEGL enables higher bit depths and on-canvas preview instead of using postage stamp-sized previews in dialogs.

What are some of your greatest successes?

Bringing GEGL from a duke-nukem-forever state, where GIMP was waiting on GEGL for all future enhancements, to GEGL waiting for GIMP to adopt it. The current development series of GIMP (2.9.x) is close to be released as 2.10 which will be the new stable; it is a featureful version with feature parity with 2.8 but a new engine under the hood. I am looking forward to seeing where GIMP will take GEGL in the future.

What are you working on right now?

One of the things I am working on – and playing with – at the moment is experiments in color separation. I’m making algorithms that simulate the color mixing behavior of inks and paints. That might be useful in programs like GIMP for tasks ranging from soft-proofing spot-colors to preparing photos or designs for multi-color silk-screening, for instance for textiles.

Which projects depend on your project? What’s the impact so far?

There are GIMP and GNOME Photos, as well as imgflo, which is a visual front-end provided by the visual programming environment noflo. GEGL (and babl, a companion library), are designed to be generally useful and do not have any APIs that could only be considered useful for GIMP. GEGL itself also contains various example and experimental command line and graphical interfaces for image and video processing.

How can I get involved? 

GEGL continues needing, and thankfully getting, contributions, new filters, fixes to old filters, improvements to infrastructure, improved translations, and documentation. Making more projects use GEGL is also a good way of attracting more contributors. With funds raised through Liberapay and Patreon, I find it easier to allocate time and energy towards making the contribution experience of others smoother.

And now a few questions just for fun…

What is your favorite place on Earth?

Tricky, I have traveled a lot and not found a single place that is a definitive favorite. Places I’ve found to be to my liking are near the equator and have little seasonal variation, as well as are sufficiently high altitude to cool down to a comfortable day high temperature of roughly 25 degrees Celsius.

Favorite ice cream?

Could I have two scoops in a waffle cone, one mango sorbet, one coconut please? :)

Finally, our classic question: what do you think cats dream about?

Some cats probably dream about being able to sneak through walls.

Øyvind Kolås, CC BY-NC-ND Ross Burton

 

 

Thank you, Øyvind, for your answers. We look forward to seeing your upcoming work on GEGL this year and beyond!

Please consider supporting Øyvind through his GEGL Liberapay or GEGL Patreon campaigns. 

Nuritzi Sanchez: Meet Shobha Tyagi from GNOME.Asia Summit 2016

This month’s community spotlight is on Shobha Tyagi, one of the volunteer organizers of GNOME.Asia Summit 2016.

Courtesy of Shobha TyagiCourtesy of Shobha Tyagi

Shobha’s history with GNOME began when she participated in the Outreach Program for Women (OPW) internship in December 2013, with GNOME as her mentoring organization. She attended her first GUADEC in 2014 while she was an OPW intern, and met Emily Chen, who introduced her to the GNOME.Asia Summit.

Passionate about helping to spread GNOME throughout Asia, Shobha was resolute to rise to the challenge of bringing GNOME.Asia Summit to her home in Delhi, India. Fast-forward two years, Shobha is proudly leading the local organizing team of GNOME.Asia, which is ready to lift its curtain in Delhi, on April 21, 2016.

We chatted with Shobha about GNOME and her experience organizing GNOME.Asia.

Why did you choose to work with GNOME for your OPW internship? To be honest, I thought that since GNOME organizes OPW, I would receive the most productive mentoring from GNOME. Sure enough, that happened! I decided to make my initial contribution to Documentation, and after that I met my guru and mentor, Ekaterina Gerasimova. Courtesy of Shobha TyagiCourtesy of Shobha Tyagi

Do you have a favorite thing about GNOME?

My favorite thing about GNOME is its people. The same people who create it, maintain it, and use it – they are what makes GNOME really great. I really enjoy committing my patches directly to the upstream repositories and meeting the contributors in person. I also get great satisfaction whenever I tell people about GNOME and let them know how they can also contribute. You submitted the winning bid to host GNOME.Asia Summit 2016; do you have any tips for those who are interested to bid for upcoming GNOME conferences? Sure! It does help if you have attended a GNOME conference in the past, but once you have made up your mind to bid, have faith in yourself and just write your proposal. Can you describe a challenge you faced while organizing the GNOME.Asia Summit and how you overcame it? There are many challenges, especially when you are the only one who knows the ins and outs of the event and have a limited amount of time. I’m surrounded by very supportive people. Even so, people expect more from the person who lays the initial groundwork. I thank the summit committee members for their tremendous help and persistence through countless IRC meetings and discussion, without which, it would have been impossible to overcome all of the small obstacles throughout the entire planning experience. What’s the most exciting part about being an organizer? The most exciting part is learning new things! Writing sponsorship documents, calling for presentations, picking up basic web development skills, identifying keynote speakers, chief guests and sponsors, amongst other things. I learned first-hand what goes into designing logos, posters, and stickers. There were also other tasks that I wouldn’t have had to do in a normal situation like arranging a day tour to Taj Mahal for a big group. Life after GNOME.Asia Summit Delhi; what is going to be your next project? After the GNOME.Asia Summit, I would like to focus my efforts on establishing a GNOME user group in Delhi. Advice for eager newcomers and first-time contributors? My advice for them is to come and join GNOME! GNOME enables you and me to contribute, and when we contribute, we help each other improve our lives. If you are committed, you can commit patches too. And now, some fun questions. What is your favorite color?  Yellow. Favorite food? All vegetarian Indian food. What is your spirit animal? Cow! They have a calm demeanor, and symbolize abundance and fertility since they represents both earth and sky. Finally, and this one is important; what do you think cats dream about? Cats dream about being loved, cared for and pampered by their master.

Shobha is helping to organize the 2016 GNOME.Asia Summit while working as an Assistant Professor at Manav Rachna International University, and pursuing a doctorate in Software Engineering. She has been a Foundation member since 2014, and has previously contributed to the Documentation team.

Thank you so much, Shobha, for sparing some of your time to talk to us! We wish you a successful Summit!

Interviewed by Adelia Rahim. 
Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl