Base: What new features do you most need?

English
#1

What do Base users most need that is missing now?

Please answer below with your ordered list of new Base features you most need (features which don’t currently exist).

This is only to collect information, not to argue for your desired features, so please keep your answers simple and concise. Provide a good enough description that a developer could implement your need without too much further direction. For each item in your list, please provide a bold face title, followed by normal face text extended description. Small screen shots are ok if they help clearly illustrate your need.

And if someone has already spelled out your need, just say it’s also your need. Obviously this is not about voting, but rather about collecting your needs so more expert people can reasonably decide what to work on. You can also up-vote other’s answers to show support for their lists.

Prefix your list with something like: Novice, Intermediate, or Advanced user.

For example your answer might look like this:

Intermediate user.

1. Multiple columns in list and combo boxes with optional column titles. Combo and list boxes are often used to select foreign keys, meaning select records which are much more complex than just a simple key. The key might be 42, and the record might be all of the information related to a person’s address. It would be very helpful to allow a pull down which shows 2,3,4, or even 10 columns of information, rather than the current limit of 1. Yes, concat(x,’ ',y, …) can be used in the current pull down, but this is messy as it doesn’t allign x and y in it’s own columns.

For example say you want to select an accounting category the pull down list might look something like this

image description

2. Foreign key pull downs in queries. Queries provide a natural place to want to simply edit tables. The problem is in editing foreign keys. The ability could be added to allow a pull down in the query for foreign keys to show the records refered to and to select the foreign key from the foreign key’s other related fields. For example the pull down might show Red, Blue, Green, and the result of the pull down selection woud be to stuff 4 related to Green in the table. Of course multiple columns as in item 1 above should be allowed here too.

Thanks for everyone’s cooperation and help!

#2

Personal surveys don’t belong in this forum!

#3

Ok, fair enough. I hesitated for a long time before asking this question because I expected just such a response. But let me ask this, if not here, then where does a question like this belong? And how can I and others reasonably find out what other’s needs are? I think this is a valid question, an important question, and a timely question, and I think this is exactly the right sort of place to ask it.

#4

Go to Bugzilla. You’ll find new feature requests there.

#5

Why not?
And if not here, where?
This is a lot more user friendly than the usability-challenged Bug Tracker.
More likely to get responses from more users and from different kinds of users by using all the available channels of communication.

Expecting end users to read some multiple page Bug tracker HowTo just to discuss a feature request is silly.
And the only responses there are from other Bug tracker users - not typical end users.

This is not some typical forum spam poll.

#6

I’ve got Bug reports still open from 18-24 mos. ago. I would hate to think some requests for NEW functions/features are going to take precedence and introduce new bugs.

#7

I share your concerns about bugs!, and one of the “needs” could be fixing bugs, perhaps specific bugs, (like how ODBC crashes which I reported to Bugzilla long ago). But because no one likes to fix someone else’s bugs, especially if there is a steep learning curve and lack of comments as is often the case, I think blending new feature development w/ bug fixing is the best formula for developer growth which will benefit us all. Learn code w/ feature enhancements. Then it’s easier to fix.

#8

Sorry, but that is just a dream. BTW have you ever gone through any of the source code? I have, and played around with some minor revisions. It’s a headache just trying to find your way around let alone fix something properly. New stuff can be even more daunting.

#9

@Ratslinger, Yes, I have worked thru the ODBC connector code in detail. Lots of source files and almost no comments. :frowning: When I finally get the time and skills for my first stab at the code, I want to add commits with only comments in them. Harmless but helpful ones. Just like stairs on the trunk of a tree, so others can also find their way up. We have to be able to maintain this beast somehow. We need a plan to accomplish that I think. I think the first step is needs assessment.

#10

Your ODBC connector code is like a grain of sand on the beach in comparison. Having worked with programs with 60K - 100K lines of code I find that was easier than the LO source. Enough for me. This is pointless.

#11

@Ratslinger, I think you’re easily the smartest and most dedicated guy here. I have to respect what you say. My last large project was 50k lines and I wrote it alone. It’s not the number of lines that is the problem, it’s the lack of the ability to read it I think. Covering 6 languages were 10k lines of comments because even I couldn’t remember what I had just done as I came back to it a year later to fix an issue. If the issue is the code is too big and scary, then we need solutions.

#12

Please, there is no way I am as you claim. At most I am somewhat tenacious. There are many smarter, more dedicated people who regularly work this forum.

#13

Ok, I’ll go first and see if anyone follows. Sorry, I have a long list I’ve been compiling. These are only the major things I want to see:

I see myself as intermediate. 30 years of off and on working w/ databases, but only 6 mo of messing with LO.

1. Design example library. I think the quickest way to learn and get results is to start with good examples. There have been many good LO examples shared here, but so far I haven’t found a LO Base example repository. I did find a OOo Base repository. And I learned much years ago from the Access NorthWind.mdb examples.

2. Add many more comments to LO Base source code and improve guides to it. New people must be able to read and understand the source code more easily.

It is clear to me that new code development and bug fixing is very slow. What we need is a better tool to allow new people to understand and extend the current code. I think a team needs to go through the code, read it and figure it out, and then document it with lots of additional comments, so new people can find their way around easier. Perhaps we even need a better guide to it. Yes, you can spend a lifetime trying to understand it, but then you get nothing done. I understand how code can get written without many comments. It makes some sense at the time.

3. Multiple columns in list and combo boxes with optional column titles. (which I described above)

4) Foreign key pull downs in tables and queries. (which I partially described above). Queries inherit relation lookups from Tables, and Forms inherit from both Tables and Queries. This to be like other similar data bases use.

5) Add ability to add Links to a variety of tables. This allows joining data tables no matter which data bases they are in.

Let me provide an example: I have a MariaDB (MySQL) database called addresses. It has tables for cities, states, zip codes, countries, and even some street information for near where I live. I use this database over and over in many of the applications I build. I need to be able to link to it from a variety of different .odb databases. Yes, I can duplicate it but that breaks the rule of not duplicating data unnecessarily.

6) Re-engineered combo and list box controls: I see these controls as the very heart of relational design and they be as clean and well designed as possible. Fix events which don’t work so well right now, add multiple fields to pull downs, fix ugly down arrow in shorter list boxes, make typing selection work better, make copy and paste work with list box.

7) Add a findFirst function. Indexes are the foundation of relational databases. Being able to move to a record via an index using a where clause is missing, and would be quite useful. (Usage example. I’ll add to this later with a better example).

8) Backup data base menu option. As LO still crashes from time to time, and for that matter will probably always crash from time to time, the developer needs a better tool to protect herself or himself as development proceeds. It is not good enough to have automatic backups, and in fact it is actually counter productive. You need backups as stages are reached where you can add a comment to say what state the development is in for that backup.

Instead, as each little bit of development is completed on a data base, the developer needs a quick and easy way to save a backup with a name made up of a current date and an optional text string to say what the backup holds that now works.

(Perhaps we could use source control, but I don’t think so. Save that for another day.)

9) Inheritable forms and reports. I often create a database that starts with just one form or one report. Then later I find I need a similar form or report, but don’t want to modify my original form or report. So I copy the form or report and begin my new edits on it. But after doing this several times, I sometimes find a thing I want to change in both the original and all copies of the form or report. Then I have to go edit each and every one of the forms or reports.

A better way would be to be able to create a form or report that is based on another form or report, so that if the underlying parent is changed the child is automatically also changed. Think css, or layered forms and reports. (To my knowledge even Access doesn’t have this capability).

#14

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.