Closed
Bug 779300
Opened 9 years ago
Closed 9 years ago
Implement desktop background colour on GNOME
Categories
(SeaMonkey :: OS Integration, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
seamonkey2.14
People
(Reporter: neil, Assigned: neil)
References
Details
Attachments
(1 file)
4.37 KB,
patch
|
iann_bugzilla
:
review+
|
Details | Diff | Splinter Review |
Now that we have the new fancy desktop background dialog, we might as well support the colour picker.
Assignee | ||
Comment 1•9 years ago
|
||
Comment on attachment 647678 [details] [diff] [review] Proposed patch > // build the file name >- nsCAutoString filePath(PR_GetEnv("HOME")); >+ nsCString filePath(PR_GetEnv("HOME")); Part of another patch? > NS_IMETHODIMP > nsGNOMEShellService::GetDesktopBackgroundColor(PRUint32 *aColor) > { >+ if (background.IsEmpty()) >+ return NS_ERROR_FAILURE; Firefox does *aColor = 0; return NS_OK here - should we be doing the same?
Assignee | ||
Comment 3•9 years ago
|
||
(In reply to Ian Neal from comment #2) > (From update of attachment 647678 [details] [diff] [review]) > >- nsCAutoString filePath(PR_GetEnv("HOME")); > >+ nsCString filePath(PR_GetEnv("HOME")); > Part of another patch? No, just random cleanup (nsStringAPI typdefs nsCAutoString to nsCString, and this also helps us avoid the mass nsCAutoString -> nsAutoCString change that has been bandied about). > >+ if (background.IsEmpty()) > >+ return NS_ERROR_FAILURE; > Firefox does *aColor = 0; return NS_OK here - should we be doing the same? The idea is that this will cause us to hide the colour picker, so that we don't try to change the background colour, since it seems likely that it would fail too.
Attachment #647678 -
Flags: review?(iann_bugzilla) → review+
![]() |
||
Comment 4•9 years ago
|
||
Pushed to comm-central: http://hg.mozilla.org/comm-central/rev/872744c69ef8
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.14
You need to log in
before you can comment on or make changes to this bug.
Description
•