It literally did nothing except look nice^W^W^W^Wterrible, as it didn't
use the Layout Kit and it pre-dates the Haiku coding style (last "real"
modification was sometime before 2005). Supposedly it saved its settings
to disk but I can't find that.
See the "pppconfig" and "ppp_up" applications in src/bin/network for
something that actually works (though the modem stuff in the kernel PPP
stack hasn't been rewritten, so those are PPPoE only at the moment.)
These buttons go to the left according to the ad-hoc rule we've
created for preflets. The right side is reserved for an Apply or OK
button and is left blank otherwise.
SetBorder(B_NO_BORDER) on tabView.
Add a BSeparatorView to draw a line between tabs and bottom buttons
Inset by B_USE_WINDOW_SPACING around buttons.
(B_USE_DEFAULT_SPACING betwen buttons and the tabview)
Also make some new const variables to make some math more opaque
i.e. don't use as many magic constants.
This works great at 12pt font size, decenly at all other sizes. There is a
bit of jitter at 13pt and 24pt for some reason when moving from a default
settings view to another settings view.
...to just DefaultSettingsView
It is just as obvious what it does in context, but shorter.
Rename the function it contains from
BuildDefaultScreenSaverSettingsView to
BuildDefaultSettingsView
Make the square a rectangle with Golden Ratio
Use Set*UIColor() instead of Set*Color(ui_color())
Use B_CONTROL_BORDER_COLOR instead of hardcoding
Sort out copyright -- Haiku, Inc. didn't exist before 2003
Use variable width spacing based on font size from ControlLook
Removed unnecessary #includes
Did a little pixel pushing to make sure that everything is spaced
nicely and to ensure everything lies on integer pixel boundries.
just noticed this crash...
when fConfigView gets deleted by selecting a translator it
deletes its child fInfoText but we were leaving the pointer
alone.
Afterwords if you changed the panel text color in Appearance
a message gets sent that checks to see if the fInfoView
pointer is NULL, and since it isn't, procedes to dereference
the pointer and *boom* the app crashes.
Fix this by setting the fInfoText pointer to NULL when fConfig
view gets deleted. That way when you change the panel text
color it doesn't attempt to dereference the stale pointer
and everything works as it should.
As you scroll through the list of translators keep the window width
constant by setting a minimum width. A little too narrow at 8pt,
and the window is too wide at 24pt, but at 12pt it is just right.
(at least for 1024x768).
The window width and height were not chosen arbitrarily, 598px
is just about 600px and almost exactly fits the width of our
widest translator (PNG translator). The height is 369px which comes
from the golden ratio of 1.62:1. The width of the translators are
set to exactly match this at 12pt font size. This way you don't get
any unexpected window resizing. At other font sizes the window does
resize, but, the contents still fit (mostly) nicely.
See screenshot for details:
http://insightfactory.tumblr.com/image/141980518317
Avoids showing the same language multiple times in the list, for example
when there are cyrillic and latin variants. It is still possible to pick
one of the variants, as they are also added as country-specific entries.
Fixes#9144.
- As suggested by Ingo, add libshared.a to the architecture name map.
This allows it to be linked by its short name like other frequently
used libraries.
- Adjust all Jamfiles referencing the lib accordingly.
* The FiltersConfigView now ensures that its current filter is deleted
before itself, as the filter's add-in would already be unloaded at
that point.
* This fixes crashing when leaving the filter config view.
* The actual problem is that the launch_daemon does not notice the
manual launch of system services (because of the missing registrar
that provides that service).
* So not checking if the print server is running actually solves the
issue; otherwise the launch_daemon starts its own server, that will
then get shut down, as there already is a print server (the one
launched by the Printers preferences).
* Closes ticket #12531.
* It still doesn't work correctly yet again, though; the servers cannot
be configured there.
* I'm leaning towards removing the server configuration there, as they
can easily changed in the add-on preferences from the same preferences
application; the way it was done was pretty much a hack. Any hard
feelings about this?
* This is used when configuring the DNS client, so resolving will not
work
* It is supposed to be a control for entering IPs, not domain names.
Fixes#12464.
When a translator is uninstalled, BTranslatorPrivate::_RemoveTranslators is
called. This method used to unload the image containing the translator after
calling Release() on it resulting in several problems:
- If the translator was still busy, e.g. translating something while being
installed, it crashed since the image was unloaded even though its refcount
was larger than 0.
- Applications using code from one of the translators (e.g. its config view)
would crash when the translator is uninstalled (this is bug #12005).
This problem is now fixed. The roster keeps track of all translators whose
image it manages (even if the translator was already removed from the roster).
It also keeps a refcount to all images. When a translator's refcount drops to
zero and it belonged to a roster at some point, it does not delete itself, but
notifies the roster that it is ready to destruct, which then removes it from
the roster if the translator is still in it, destroys the translator, decrements
the refcount of the image and if the new refcount is zero, unloads the image.
All of this is done in a message handler, since if the translator called
TranslatorDeleted like before, the unloaded image would be referenced when
the stack is walked up.
Finally, the DataTranslations preflet is required to Acquire() the translator
whose config view it is showing, because otherwise its refcount could be reduced
to 0 and the image unloaded. BTranslatorRoster now enables users to acquire a
translator by ID. By the time the translator has to be released, it might not
be part of the roster anymore though. Since BTranslatorRoster tries not to give
out raw pointers to the translators it manages, users who acquire a translator
through a roster now are given a BTranslatorReleaseDelegate, which allows for
releasing the BTranslator exactly once and then self-destructs.
Signed-off-by: Axel Dörfler <axeld@pinc-software.de>
