Adobe XD Repeat Grid Feature

[tim_occ]

Hi together,

today I found a really cool feature in Adobe XD, they call it "repeat grid". It is really easy to create grid based layouts, and I want have it in Scribus too.
Check out the demo video: https://www.youtube.com/watch?v=42VCB42TKp4

greets,
Martin

[GarryP]

Very nice.

I'm not sure how useful it would be in Scribus - I can't think of many use cases off the top of my head: catalogues; yearbooks; that's about it - but anything that makes tables easier to use would be a bonus.

I don't use tables as they aren't very well implemented (as of 1.4.6) but if they worked better I might start to do so.

On a related note, dragging the margins to resize them looks like a nice feature and could be something that might be useful in multi-column text frames to resize the gap between columns. Not very high-priority though.

Maybe this will start a good little discussion on what people want from tables in Scribus. Maybe someone has some ideas that are too good to ignore.

[CGood]

Maybe I'm out of place here, and I don't wish to discourage creative thought, but I don't want development resources spread thinner chasing after this or that cool but optional feature. Had Scribus more developers and resources, maybe I'd feel different, but in the current reality I'd rather some peripheral capabilities be cut off completely - current but poorly implemented ones.

Tables would be my poster child. Better a table be created elsewhere, in a program that does tables really well, and imported, as an image if necessary. As far as I can tell, tables currently are almost unusable in Scribus - and that's OK - I can get a table elsewhere. I like the idea of sticking to a central mission and doing it well. Why can't I create original content externally - in Gimp, Darktable, Inkscape, Krita, and so on, and use Scribus to do what it does really well, to create final printable assemblage? I'd rather Scribus narrow the focus.

[GarryP]

I agree with pretty much everything you've said CGood, and have said very similar things on this forum.

My views in this area are liberally scattered around this forum so I won't repeat them here. Suffice to say that I'm all for adding new features into Scribus as long as they add real value, while at the same time I'd like to see some features removed until they work properly. It would be great if "superfluous" features could be dropped so that the core functionality could be made rock solid.

However, there are some practicalities that need to be taken into consideration:

1. The Developers Work For Free

As I'm sure most people know, the time and effort that the developers put into Scribus is expended without recompense. Also, the developers work only when they want to and in their own time. This means that there is no leverage that can be applied to the developers so you can't force anything to happen. There's no "boss" that gets to tell them what to do. Try to force a developer to work on something they don't want to and they'll just walk away, to the detriment of the project. This leads on to...

2. People Do What They Like

People like to work on things that they enjoy or are interested in. For instance, more people are likely to want to be working on making a game explosion looking cool than making sure that exception trapping and error reporting is bulletproof. It's just human nature; who wants to check that all zero-division possibilities have been covered when you can work on adding a new cool feature? This leads on to...

3. Work Done Has Weight

When someone has put time and effort into something, they have given part of themselves to that thing. The thing becomes "infused" with part of their life. Because of this, some developers can get emotionally attached to their creations. Some even refer to the software as their "baby". They can no more remove something from the software than they could take something from their child. This is coupled with...

4. There Are No Usage Statistics

There is no way of knowing which parts of Scribus are actually being used and therefore no way of knowing which parts can be "safely" removed. To put it another way, for every person saying "I want this removed" there will be another saying "Hey, I was using that". Removing features that people are using will more likely drive people away from Scribus even if - in the long run - it is the "right" thing to do (whatever "right" means). This is also coupled with...

5. Most Users Like Simplicity

I think it would be safe to say that most Scribus users are not technically proficient with all aspects of computers. Most people just want to put a quick document together, and they don't have the time/patience/experience to learn another application. For instance, Inkscape can create vector art that is far superior to what can be created in Scribus but if someone can't learn how to properly use Inkscape (for whatever reason) then they're going to stick with what Scribus can do. The same goes for GIMP and others. This leads on to...

6. Experts Can Do Their Own Thing

If someone knows how to, for instance, use GIMP to create/manipulate an image and then import it into Scribus then they are free to do so. They can bypass the Scribus image tools and use whatever software they're comfortable with. No-one is forcing them to use anything. The same goes for tables, vectors, etc. etc. If an expert doesn't like the way that Scribus does, for example, tables then they can ignore the tools that Scribus gives them and use something else. Non-experts, on the other hand, may not be comfortable using external tools and just want to "get something done" even if it's simplistic. If someone wants more, then they will have to put the effort in to learn more.

Summary(?)

(Is anyone still reading this?) Anyway, in the past I've suggested adding new features and also suggested that some features should be removed. To take two specific instances, personally I think Scribus could do with a better way of zooming and have given a suggestion of how to do this, while on the other hand I can't think of a reason why Scribus has a "Fish Eye Lens" tool and have suggested removing it. This was all from my own personal point of view and I'm sure that other people have their own. What's best for one person may not be best for another.

If the Scribus developers were organised in such a way that they could be assigned roles and goals by some controlling force then I'm sure it would be possible for  the core Scribus code to become rock solid while, at the same time, certain peripheral functions could be "side-tracked". However, as it is, the developers do what they want to do and there's nothing anyone can do about it. And there's nothing that should be done about it either. Trying to force volunteers to do something they don't want to do just makes the volunteers walk away and everyone is worse off. (CGood: I'm not suggesting that you'd like to force anything, this is for the general readership.)

The developers do - and have done - a fantastic job in getting Scribus where it is today. It's a very important piece of software that's woefully under-supported considering how many people use it. It all comes down to what could be an open source mantra: "If you want to improve something, learn to code and then improve it". As an example, take Martin's excellent work on the Indigo Dock http://forums.scribus.net/index.php/topic,1617.0.html I don't think anyone asked him to do it but he took up the challenge for himself and it's been coming along very nicely indeed. I have my fingers crossed that enough work is done on it that it becomes the new interface for Scribus. That would be a lovely success story.

One final note: While I've said that getting developers to work on specifics is pretty much impossible - especially with such a small team as Scribus has - I'm still sure that discussions about how things should work are important. Even if nothing comes of them in the short term, there's a chance that someone looking for a little coding project might find them and have a go at improving things. And if these improvements get into the Scribus code then we all benefit.

[CGood]

Hi GarryP, It's clear you've used and thought about Scribus far more than I have. You are right of course that the most scarce resource is the time and attention of the developers. And I don't want to denigrate some developer's creation when I say that this or that feature should get grayed out or commented out...

I feel Scribus is very important, a project I want to keep getting better, and a poster child of how open projects can offer things of wide value. It has become the most natural way I put words on paper. I feel like I'm shackled and straightjacketed when I have to try to use "word processors" to work with formatting text and images to go on paper. I don't want to discourage the devs.

[tim_occ]

Hey guys,

I don't wanted open the box of pandora about new features.   But I agree with you, Scribus has to focus on core features of a DPT instead of become overloaded with a lot of "bonus" features. Scribus has a lot of places which need an improvement. In my eyes UI is the biggest one. But outside of Scribus there are places too. Take a look to the webpage, there is no link to this forum here. However, in my opinion it is necessary to polish Scribus (webpage, user interface, documentation/wiki) to get a bigger community and much more developer or contributors.

Garry P, I agree with you when you say: "If you want to improve something, learn to code and then improve it". That was my intention as I started the IndigoDock project. BTW: the dock itself is stable enough for usage. But a general UI polish is still missing.

greets,
Martin

[GarryP]

I've already said my piece about features so I won't repeat myself, but...

It's all just a matter of getting more good people involved but Desktop Publishing simply isn't "sexy". If someone has some time to spare and they can either use that time to, for example, (a) add a new feature to Blender that will help people model hairs that move independently or (b) make sure that the Scribus spell checker works with the Belgian language, then what are they going to choose to do?

As you know, people will spend their own time doing stuff they they enjoy doing, and there's nothing that can - or should - be done about that. As mentioned in another post, if the Scribus website was more eye-catching then maybe there might be more people that would "sign up". If it looks like an enjoyable thing to do then people might want to get more involved. Either that or start dragging people in off the streets!

The developers are doing an amazing job but there simply aren't enough of them. It's fantastic that people like yourself are involved and getting stuff done but there's so much work to do. The bug tracker has issues going back a decade or more (and they're not just feature requests, they're actual bugs that stop the software running properly).

Anyway, not sure where I was going with this but I agree with what you've said. The project needs more people getting involved. How that's done however, I couldn't really say.